Daten nach ihrer Bedeutung modellieren
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)
Lernleitfaden zu Kapitel 2 des Kurses Data Architect. Lesen Sie zuerst die sechs Module; diese Seite hilft Ihnen zu prüfen, was hängen geblieben ist.
Über diesen Lernleitfaden. Er beruht ausschliesslich 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 ist die Grundlage für den Prüfungsbereich Data Modeling and Database Design, der ein Viertel der Prüfung ausmacht. Es behandelt das Denken; das nächste Kapitel, Salesforce-Datenarchitektur, behandelt, wie die Plattform es baut. Das meiste, was zu Objekten, Feldern und Beziehungen geprüft wird, braucht also beide Kapitel.
Für die Prüfung
Abschnitt betitelt „Für die Prüfung “Die Punkte aus diesem Kapitel, die in der Prüfung am ehesten zählen. Jeder ist einem Prüfungsziel zugeordnet und verweist auf die Stelle, an der er behandelt wird. Haken Sie sie ab.
DM-1: Techniken für den Entwurf eines Salesforce-Datenmodells vergleichen
- Ich kann den Unterschied zwischen einem konzeptionellen, einem logischen und einem physischen Datenmodell erklären und wofür jedes da ist. (Das Modell in Salesforce umsetzen)
- Ich finde mögliche Entitäten in einer Anforderung und unterscheide eine Person, die eine Aufgabe erledigt, von einem Stück Daten. (Substantive liefern mögliche Entitäten)
- Ich kann die Krähenfuss-Notation lesen und zeichnen: eins, viele und die zweite Markierung für optional oder erforderlich. (Die Linien lesen, Auch die Optionalität zählt)
- Ich kann die Kardinalität einer Beziehung benennen: eins zu eins, eins zu viele, viele zu viele. (Fragen Sie «eins oder viele?»)
- Ich weiss, dass eine Viele-zu-viele-Beziehung zu einer eigenen Entität wird, in Salesforce meist ein Verbindungsobjekt mit zwei übergeordneten Objekten. (Beziehungen können zu Dingen werden)
- Ich weiss, wann eine Beziehung eine Historie braucht (einen Datensatz mit Start- und Enddatum) statt eines Felds, das überschrieben wird. (Zeit verändert Beziehungen)
- Ich kann eine gute eindeutige ID wählen und weiss, warum ein natürlicher Schlüssel oder alles mit personenbezogenen Informationen riskant ist. (Dann müssen wir über eindeutige IDs sprechen)
- Ich kenne den Unterschied zwischen einem natürlichen Schlüssel und einem Surrogatschlüssel und weiss, dass ein Datensatz mehrere externe Kennungen tragen kann. (Natürliche Schlüssel und Surrogatschlüssel)
- Ich weiss, dass ein Feld vom Typ Automatische Nummer eine lesbare Nummer ist, nicht die Salesforce-ID des Datensatzes. (Beziehungen hängen von eindeutigen IDs ab)
- Ich kann die erste, zweite und dritte Normalform anwenden und ein Feld erkennen, das mehrere Werte enthält oder eine Tatsache über etwas anderes wiederholt. (Eine einfache Art, über 1NF, 2NF und 3NF nachzudenken)
- Ich kann erklären, wann man bewusst denormalisiert (Benutzer, Berichte, Volumen) und was es kostet. (Bis zur dritten Normalform entwerfen, dann zurückrudern)
- Ich kann für eine Werteliste zwischen einer Auswahlliste und einer Nachschlagebeziehung zu einem Objekt entscheiden. (Nachschlagen oder Auswahlliste?)
- Ich weiss, dass ein benutzerdefinierter Berichtstyp höchstens vier Objektbeziehungen erlaubt, und warum das für tiefe Modelle wichtig ist. (Nachschlagen oder Auswahlliste?)
- Ich weiss, wann Master-Detail passt (das untergeordnete Element wird nie neu zugeordnet) und wann eine Nachschlagebeziehung sicherer ist, einschliesslich der Empfehlung von Salesforce, nicht mehr als 10’000 untergeordnete Datensätze an einem übergeordneten zu haben. (Beziehungen werden zu Plattformentscheidungen)
- Ich weiss, warum man polymorphe Beziehungen vermeidet, wo es geht. (Beziehungen werden zu Plattformentscheidungen)
- Ich weiss, dass eine Geschäftsentität nicht automatisch ein benutzerdefiniertes Objekt bedeutet: Sie kann ein Standardobjekt sein, ein Feld, Konfiguration oder Daten, die ausserhalb von Salesforce liegen. (Eine Geschäftsentität heisst nicht automatisch ein benutzerdefiniertes Objekt)
Über die Prüfung hinaus
Abschnitt betitelt „Ü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.
- Vergessen Sie Salesforce für einen Moment. Modellieren Sie das Geschäft, bevor Sie es auf Account und Kontakt abbilden.
- Hören Sie auf das Wort, das zwei Dinge verbirgt. Bei Steve Trucking war «Kunde» ein Handelspartner und ein Empfänger.
- Das Modell ist Teil des Gesprächs. Ihr erstes Modell soll nicht richtig sein; es soll Ihnen zeigen, wo Sie falschliegen.
- Benennen Sie die Linien. Zwei Modelle mit denselben Kästen können Verschiedenes bedeuten.
- Fragen Sie bei jeder Beziehung «jetzt oder im Lauf der Zeit?»
- Eindeutig, unveränderlich, bedeutungslos, niemals personenbezogen.
- Legen Sie eine Tatsache dorthin, wo sie hingehört, rudern Sie dann bewusst zurück und schreiben Sie das Warum auf.
- Denormalisierung beseitigt keine Komplexität; sie verschiebt sie. Wissen Sie, wem die Wahrheit gehört.
- Eine Quelle der Wahrheit, viele Formen: Bildschirme, Berichte, das Warehouse und KI.
- Entwerfen Sie nicht aus dem Setup heraus. Zeichnen Sie das Modell, bevor Sie auf Neues benutzerdefiniertes Objekt klicken.
- Verfolgen Sie jede physische Entscheidung zurück zu etwas, das das Geschäft braucht.
Wichtige Begriffe
Abschnitt betitelt „Wichtige Begriffe “| Begriff | In einer Zeile |
|---|---|
| Entität | Ein Ding, das dem Geschäft wichtig ist und über das es Daten führt |
| Mögliche Entität | Ein Substantiv, das eine Entität werden könnte, sobald Sie danach gefragt haben |
| Attribut | Eine Tatsache, die eine Entität beschreibt |
| Beziehung | Wie zwei Entitäten verbunden sind, in der Sprache des Geschäfts benannt |
| Kardinalität | Wie viele der einen mit wie vielen der anderen zusammenhängen |
| Optionalität | Ob die Beziehung erforderlich ist oder null sein kann |
| Krähenfuss | Die Markierung für «viele» am Ende einer Linie |
| Verbindungsobjekt | Die Art, wie Salesforce eine Viele-zu-viele-Beziehung baut: ein untergeordnetes Objekt beider übergeordneter |
| Konzeptionelles Modell | Was es im Geschäft gibt und wie es zusammenhängt; kein Salesforce |
| Logisches Modell | Die Daten: Attribute, eindeutige IDs und Beziehungen, noch an keine Plattform gebunden |
| Physisches Modell | Wie die Plattform es bauen wird: Objekte, Felder und Beziehungstypen |
| Natürlicher Schlüssel | Eine Kennung, die es im Geschäft schon gibt, wie die FIN eines Lastwagens |
| Surrogatschlüssel | Eine Kennung, die nur geschaffen wird, um den Datensatz zu identifizieren |
| Externe Kennung | Die ID eines anderen Systems für denselben Datensatz, behalten und zugeordnet |
| Normalisierung (1NF, 2NF, 3NF) | Jede Tatsache dorthin legen, wo sie hingehört: ein Wert pro Feld, Tatsachen über den ganzen Schlüssel, keine Tatsachen über andere Tatsachen |
| Denormalisierung | Daten bewusst kopieren oder abflachen, aus einem Grund, den Sie benennen können |
| Änderungsanomalie | Dieselbe Tatsache an vielen Stellen gespeichert, sodass eine Änderung einige Kopien falsch zurücklässt |
Prüfen Sie sich
Abschnitt betitelt „Prüfen Sie sich “Kurze Szenarien im Stil des Kurses. Entscheiden Sie sich für Ihre Antwort, bevor Sie sie aufklappen.
1. Ein Unternehmen sagt Ihnen, eine Crew fährt einen Lastwagen. Sechs Wochen später fragt jemand, welche Crew an einem bestimmten Tag Lastwagen 117 hatte. Was hätte das Modell haben sollen?
Eine Crew-Zuweisung: die Beziehung zwischen Crew und Lastwagen als eigener Datensatz, mit Startdatum, Enddatum und Tour. Crews und Lastwagen sind im Lauf der Zeit viele zu viele, und das Geschäft interessiert sich für die Historie. Ein Feld auf dem Lastwagen wäre überschrieben worden. Lesen Sie noch einmal Zeit verändert Beziehungen.
2. Ein Team schlägt vor, die Telefonnummer jedes Empfängers als eindeutige ID zu verwenden, «weil sie eindeutig ist». Was sagen Sie?
Sie fällt durch die Tests: Telefonnummern ändern sich und werden geteilt, also ist sie weder unveränderlich noch verlässlich eindeutig, und sie ist eine personenbezogene Information, die in jedes System kopiert würde, das auf den Datensatz verweist. Verwenden Sie eine bedeutungslose generierte ID und behalten Sie die Telefonnummer als Attribut. Lesen Sie noch einmal Dann müssen wir über eindeutige IDs sprechen.
3. Eine Lieferung hat die Felder Artikel 1, Artikel 2 und Artikel 3. Eine Lieferung mit vier Artikeln kommt an. Was ist das eigentliche Problem, und die Lösung?
Das Modell hat eine sich wiederholende Struktur in Feldern versteckt (ein Problem der ersten Normalform). Die Lösung ist kein Feld Artikel 4; es ist eine Entität Lieferposition, untergeordnet zur Lieferung, sodass jeder Artikel ein Datensatz ist. Lesen Sie noch einmal Erste Normalform.
4. Jede Lieferung speichert den Namen der Leitung des Verteilzentrums. Die Leitung wechselt. Was ist schiefgelaufen?
Eine Tatsache über etwas anderes (das Verteilzentrum) wurde auf der Lieferung gespeichert: ein Problem der dritten Normalform, und jetzt eine Änderungsanomalie über Hunderte von Datensätzen. Die Leitung gehört zum Verteilzentrum; die Lieferung verweist auf das Verteilzentrum. Lesen Sie noch einmal Dritte Normalform.
5. Die Art des Stopps (nur Lieferung, mit Installation, mit Mitnahme) braucht eine Dauer, Fähigkeiten der Crew und eine Checkliste. Auswahlliste oder Objekt?
Ein Objekt. Es hat mehr als eine Spalte an Informationen, wird vom Geschäft gepflegt und ändert sich nach eigenem Zeitplan. Der Status einer Lieferung, eine kurze, stabile Liste von Bezeichnungen, bleibt eine Auswahlliste. Lesen Sie noch einmal Nachschlagen oder Auswahlliste?.
6. Partner wollen eine Pünktlichkeits-Scorecard nach Region, und die Region liegt beim Verteilzentrum. Sie kopieren die Region auf jede Lieferung. Was müssen Sie entscheiden?
Wem die Wahrheit gehört, wie die Kopie synchron bleibt und ob alte Lieferungen die Region behalten sollen, die galt, als sie stattfanden, oder dem Verteilzentrum folgen, wenn es umzieht. Die Denormalisierung hat die Komplexität verschoben, nicht beseitigt. Lesen Sie noch einmal Manchmal gewinnen die Berichte.
7. Ein Trick wie Sitz könnte mit Hunderttausenden Haustieren verknüpft sein. Master-Detail oder Nachschlagebeziehung von Haustiertrick zu Trick?
Eine Nachschlagebeziehung. Die Empfehlung von Salesforce lautet nicht mehr als 10’000 untergeordnete Datensätze an einem übergeordneten, und ein beliebter Trick würde das überschreiten. Master-Detail passt von Haustiertrick zu Haustier, weil der Trick eines Haustiers nie neu zugeordnet wird und ein Haustier nur wenige Tricks kann; ausserdem ermöglicht es erst, dass das Haustier seine Zahl Anzahl Tricks per Rollup bildet. Lesen Sie noch einmal Sitz, Bleib, Modell.
Weiterlesen
Abschnitt betitelt „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.