Stammdaten und Identität

🌐 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 6 des Kurses Data Architect. Lesen Sie zuerst die sechs Module, einschließlich des Durchgangs zu Checkpoint 1; 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 trägt den Prüfungsbereich Master Data Management (5 %) und die Einzelsicht auf den Kunden aus Salesforce Data Management. Nach Gewicht ist er klein, aber seine Ideen (Autorität, Abgleich, Survivorship) tauchen in vielen anderen Szenarien auf. Die Zahlen der Plattform ändern sich, also prüfen Sie die aktuellen, bevor Sie sich darauf verlassen.

Für die Prüfung

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

MDM-2: ein Golden Record und ein System der Wahrheit

• Ich weiß, dass Autorität pro Attribut vergeben wird, nicht pro Datensatz: Ein Account kann Felder haben, die im ERP geführt werden, und Felder, die in Salesforce geführt werden. (Die Wahrheit gehört zu einem Attribut)
• Ich frage, wo jedes Attribut angelegt, bearbeitet und referenziert wird und wie hoch seine Änderungslatenz ist. (Angelegt, bearbeitet, referenziert, und wie schnell?)
• Ich kann eine Autoritätskarte bauen, und ich weiß, dass geschäftlicher Eigentümer und maßgebliches System nicht dasselbe sind. (Bauen Sie eine Autoritätskarte)
• Ich weiß, dass sich die Autorität im Lebenszyklus ändern kann (ein Interessent in Salesforce wird zu einem vom ERP gesteuerten Kunden) und dass eine Kopie keine Autorität ist. (Die Autorität ändert sich im Lebenszyklus, Eine Kopie ist keine Autorität)

MDM-1: Techniken des Stammdatenmanagements

• Prüfungswissen: Ich kenne die vier MDM-Implementierungsstile, Registry, Konsolidierung, Koexistenz und zentralisiert: was jeder zentralisiert und ob er Werte zurückschreibt. (Die vier nebeneinander)
• Ich kann die vier MDM-Stile unterscheiden: Registry, Konsolidierung, Koexistenz und zentralisiert, und den leichtesten wählen, der das Problem löst. (Die vier nebeneinander)
• Ich weiß, dass ein kanonisches Datenmodell die Struktur harmonisiert, aber nicht über die Autorität entscheidet. (Ein gemeinsames Modell ist keine gemeinsame Wahrheit)
• Ich kenne die Reihenfolge: harmonisieren, dann abgleichen, dann konsolidieren. (Harmonisieren, dann abgleichen, dann konsolidieren)
• Ich weiß, dass Schwellenwerte die Fehlertoleranz ausdrücken und Anreicherung eine Herkunft braucht. (Schwellenwerte, Prüfung und Anreicherung)
• Prüfungswissen: Ich kenne das Hierarchiemanagement: Übergeordneter Account (Parent Account) baut die Hierarchie (die Lightning-Ansicht zeigt bis zu 2.000 Accounts, ohne Personenaccounts), Hierarchien haben oft eine geteilte Stammdatenhoheit, und ein Unternehmen kann mehrere gültige Hierarchien haben. (Auch Hierarchien sind Stammdaten, Eine Hierarchie, mehrere Master)

MDM-3: die gewinnenden Attribute wählen

• Ich halte Abgleichen, Zusammenführen und Survivorship auseinander. (Abgleichen, Zusammenführen und Survivorship)
• Ich kenne die Survivorship-Regeln: der neueste, der häufigste, Quellenpriorität, und ich weiß, dass jede Regel einen Eigentümer braucht. (Survivorship: Welcher Wert gewinnt?)
• Ich weiß, dass ein Treffer kein Zusammenführen verlangt, und ich führe nur mit einem klaren Gewinner zusammen, nachdem ich zuerst entschieden habe, was mit den untergeordneten Datensätzen passiert. (Ein Treffer verlangt kein Zusammenführen, Meine Regel fürs Zusammenführen: ein klarer Gewinner)
• Prüfungswissen: Ich weiß, was ein Zusammenführen von Accounts in Salesforce tut: bis zu drei Datensätze, ein Hauptdatensatz, das älteste Erstellt von und Erstellungsdatum bleiben, die anderen landen im Papierkorb, und Kontaktpunktobjekte werden bei Personenaccounts nicht zusammengeführt. (Was ein Zusammenführen in Salesforce tatsächlich tut)

SDM-3: eine Einzelsicht auf den Kunden

• Ich weiß, dass die Identitätsauflösung in Data 360 Quellprofile zu einem einheitlichen Profil verknüpft und die Verknüpfungen zurück behält: am nächsten an einer Registry. (Die Identitätsauflösung beantwortet „Wer?“)
• Prüfungswissen: Ich kenne die Abgleichsregeln in Data 360: Alle Kriterien einer Regel müssen zutreffen, jede Regel kann zutreffen; mehr Kriterien für Genauigkeit, weniger für Konsolidierung. (Abgleichsregeln)
• Ich kenne die Abgleichsmethoden (Exact, Exact Normalized, Fuzzy mit drei Präzisionsstufen): Eine weniger präzise Methode erhöht die Konsolidierung, und das Risiko falscher Treffer. (Abgleichsregeln)
• Prüfungswissen: Ich weiß, dass Abstimmungsregeln (Last Updated, Most Frequent, Source Priority) entscheiden, was das einheitliche Profil zeigt, aber die Quellen nicht ändern; Kontaktpunkte werden nicht abgestimmt. (Abstimmung ist immer noch kein Stammdatenmanagement)
• Ich kann je nach Aufgabe zwischen Duplikatverwaltung, Identitätsauflösung und einer eigenen MDM-Plattform wählen. (Drei Werkzeuge für drei Aufgaben)

MDM-4 und Daten in beide Richtungen

• Ich weiß, dass Daten in beide Richtungen nicht zwei Master heißen: Eine Bearbeitung eines dem ERP gehörenden Felds in Salesforce ist eine Anfrage, also entwerfe ich anfragen → prüfen → annehmen → veröffentlichen, mit einem ausstehenden Zustand. (Daten in beide Richtungen heißen nicht zwei Master, Wenn der Master Nein sagt)
• Ich weiß, wie man Schleifen und Kollisionen vermeidet: eine auslösende Änderung von ihrem Echo unterscheiden und entscheiden, welche Felder als eine Transaktion gemeinsam reisen. (Schleifen und Kollisionen)
• Für einen Kunden in zwei ERPs kann ich eine Hierarchie, gleichrangige Accounts oder einen Account mit einem untergeordneten Datensatz pro ERP wählen, je nachdem, wie gut der Kunde seine ERPs synchron hält. (Ein Kunde, zwei ERPs, Fragen Sie, wie die ERPs synchron gehalten werden)

Checkpoint 1: Teil 1 zusammensetzen

• Prüfungswissen: Ich weiß, welche externen Lizenzen die Standardfreigabe mitbringen: Customer Community Plus und Partner Community, die Rollen für die externen Benutzer brauchen; Customer Community nutzt Freigabesätze. (Wer was sieht, und wer eine Lizenz braucht)

Ü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.

• „Einzige Quelle der Wahrheit“: Welche Wahrheit? Es ist eine Architektur der Wahrheit, nicht ein Datensatz.
• Machen Sie die Autorität im Schema sichtbar: ein Präfix für Felder, die einem anderen System gehören.
• Vertrauen braucht mehr als einen Wert: Quelle, letzte Bestätigung, wer ihn geändert hat.
• Beginnen Sie mit dem Problem, nicht mit dem MDM-Produkt. MDM ist eine geschäftliche Entscheidung über Autorität.
• Verknüpfen ist kein Stammdatenmanagement.
• Wo falsche Treffer teuer sind, gleichen Sie absichtlich zu wenig ab.
• Behalten Sie Duplikate aus externen Ladevorgängen, wenn Sie vielleicht zurückverfolgen müssen.
• Ein einheitliches Profil ist eine Karte. Ein Golden Record ist eine Entscheidung.
• Anzeige ist keine Autorität.
• Identität zu vereinheitlichen hebt keine Sicherheitsgrenzen auf.
• Das Schwierigste sind die bidirektionalen. Geteilte Autorität ist nicht das Problem; unklare Autorität ist es.
• Lassen Sie eine abgelehnte Anfrage nie zu konkurrierender Wahrheit werden.
• Ein Feld, das sagt „Das sind Stammdaten“, steuert die Bearbeitbarkeit, nicht ein Datensatztyp.
• Die ERPs kontrollieren wir nicht. Wir kontrollieren, wie wir sie in Salesforce darstellen.

Wichtige Begriffe

Begriff	In einer Zeile
Stammdatenmanagement (MDM)	Die maßgebliche Identität und die Werte wichtiger Daten über Systeme hinweg festlegen und steuern
Autoritätskarte	Für jedes Attribut: wer es anlegt, wem die Entscheidung gehört, welches System maßgeblich ist, wer es ändern darf
Golden Record	Eine gesteuerte Entscheidung darüber, welche Werte maßgeblich sind
Hybrider Golden Record	Ein Datensatz, bei dem einige Attribute woanders geführt und hereinkopiert werden und andere lokal gehören
Registry	MDM, das Datensätze als dieselbe Entität verknüpft, ohne die Quellen zu ändern
Konsolidierung	MDM, das Daten zentral kombiniert, meist für die Analytik, ohne zurückzuschreiben
Koexistenz	MDM, das den geführten Wert entscheidet und an die Quellen zurück veröffentlicht
Zentralisiertes MDM	MDM, bei dem gesteuerte Daten im Master angelegt und verteilt werden
Kanonisches Datenmodell	Eine vereinbarte Unternehmensform für ein Konzept, um Systeme einander zuzuordnen
Harmonisierung	Werte vergleichbar machen: Standardformate, Codes und Abkürzungen
Abgleich	Entscheiden, ob Datensätze dasselbe darstellen
Survivorship	Regeln dafür, welcher Wert gewinnt, wenn Quellen sich widersprechen
Hauptdatensatz (Principal)	Beim Zusammenführen in Salesforce der Datensatz, der überlebt und seine ausgeblendeten und schreibgeschützten Felder behält
Abgleichsmethode	Wie ein Abgleichskriterium in Data 360 Werte vergleicht: exakt, exakt normalisiert oder unscharf (Fuzzy)
Identitätsauflösung	Der Abgleich von Quellprofilen zu einheitlichen Profilen in Data 360
Einheitliches Profil	Ein Satz von Schlüsseln, der Quelldatensätze verknüpft, die eine Person oder ein Unternehmen darstellen
Abstimmungsregeln	Regeln in Data 360 dafür, welchen Wert ein einheitliches Profil zeigt
Hierarchie mit geteilter Stammdatenhoheit	Eine Hierarchie, deren Zweige verschiedenen Systemen gehören

Prüfen Sie sich

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

1. „Salesforce ist unsere einzige Quelle der Wahrheit für den Kunden.“ Was fragen Sie?

Welche Wahrheit? Autorität gilt pro Attribut: Dem ERP gehören vielleicht rechtlicher Name, Rechnungsadresse und Kreditlimit, während Salesforce der Account Executive und die Erfolgsstufe gehören. Bauen Sie eine Autoritätskarte. Lesen Sie noch einmal Die Wahrheit gehört zu einem Attribut.

2. Der Service muss sehen, dass ein Salesforce-Kontakt dieselbe Person ist, die online gekauft hat. Niemand braucht eine Änderung der Systeme. Welcher MDM-Stil?

Eine Registry: die Datensätze als eine Identität verknüpfen, ohne die Quellen zu ändern, was die Identitätsauflösung in Data 360 tut. Wählen Sie das leichteste Muster, das das Problem löst. Lesen Sie noch einmal Registry: Sag mir, wer wer ist.

3. Survivorship ist für jedes Feld auf „der neueste gewinnt“ gesetzt. Jemand ändert die Salesforce-Kopie des rechtlichen Namens, der dem ERP gehört. Was passiert, und was ist falsch?

Der neueste Wert gewinnt, und die Kopie überschreibt die Autorität. „Der neueste“ ist eine Aussage über Vertrauen, die zu manchen Attributen passt (eine Mobilnummer) und zu anderen nicht. Wo die Autoritätskarte sagt, dass das Feld dem ERP gehört, gewinnt das ERP. Lesen Sie noch einmal Survivorship: Welcher Wert gewinnt?.

4. Kundendatensätze aus einem Altsystem werden importiert und treffen auf bestehende Accounts. Zusammenführen?

Seien Sie vorsichtig. Ein Treffer verlangt kein Zusammenführen, und das Zusammenführen zerstört die Alt-IDs und älteren Werte, die Sie vielleicht nachverfolgen müssen. Verknüpfen Sie sie, es sei denn, es gibt einen klaren Gewinner und das Duplikat fügt nichts hinzu, was Sie brauchen. Lesen Sie noch einmal Meine Regel fürs Zusammenführen: ein klarer Gewinner.

5. Das einheitliche Profil in Data 360 zeigt Dallas. Das Team sagt, Dallas sei jetzt der goldene Wert für jedes System. Ist es das?

Nein. Die Abstimmung entscheidet, was das einheitliche Profil zeigt; sie ändert die Quellen nicht und trifft keine Stammdatenentscheidung. Wenn jedes System einen gesteuerten Wert verwenden muss, ist das Koexistenz oder zentralisiertes MDM, mit einem Eigentümer. Lesen Sie noch einmal Abstimmung ist immer noch kein Stammdatenmanagement.

6. Medizinische Datensätze abgleichen gegenüber Marketingdatensätzen: dieselben Regeln?

Nein. Ein falscher Treffer im Marketing schickt das falsche Angebot; in medizinischen Daten kombiniert er die Krankengeschichten zweier Menschen. Legen Sie die Strenge nach dem Preis des Irrtums fest, und gleichen Sie zu wenig ab, wo Vermischung teuer ist. Lesen Sie noch einmal Der Preis des Irrtums.

7. Der Vertrieb will eine dem ERP gehörende Rechnungsadresse aus Salesforce heraus aktualisieren. Wie entwerfen Sie das?

Als Anfrage, nicht als Bearbeitung: Salesforce schickt den vorgeschlagenen Wert, das ERP prüft und nimmt ihn an und veröffentlicht den maßgeblichen Wert zurück. Halten Sie bis dahin einen ausstehenden Zustand, und behandeln Sie Ablehnung, Kollisionen und Echos. Lesen Sie noch einmal Daten in beide Richtungen heißen nicht zwei Master.

8. Bei Steve Trucking erscheint derselbe John Smith in den Ladelisten zweier Handelspartner. Ihn vereinheitlichen?

Nein, bewusst nicht. Jeder Partner darf nie die Empfänger eines anderen sehen, und eine einheitliche Identität ist die Brücke, über die es durchsickert. Gleichen Sie zu wenig ab, wo Vermischung teuer ist; wenn ein Partner wiederkehrende Empfänger erkennen will, beschränken Sie es auf diesen einen Partner. Lesen Sie noch einmal Würde ich Empfänger über Partner hinweg vereinheitlichen?.

9. Jemand aus dem Vertrieb schickt eine neue Straße für eine Adresse, die dem ERP gehört, während in derselben Minute jemand im ERP den Ort ändert. Was entscheiden Sie?

Ob die Adresse als eine Transaktion reist. Wenn ja, gehen alle Felder gemeinsam oder keines, und die Anfrage wird abgelehnt, weil sich die Adresse inzwischen geändert hat. Entscheiden Sie das vor der ersten Kollision, und denken Sie daran, dass die Anfrage darum bittet, den Wert des ERP zu ändern, und ihn nicht selbst ändert. Lesen Sie noch einmal Schleifen und Kollisionen.

10. Ein Auftraggeber führt einen seiner Kunden in zwei ERPs, und niemand hält die beiden Datensätze synchron. Der Vertrieb will einen Account. Was empfehlen Sie?

Nicht einen Account. Wenn er die Datensätze nicht einmal in seinen eigenen ERPs synchron halten kann, kann Salesforce es nicht für ihn tun: Stellen Sie sie als gleichrangige Accounts oder als Hierarchie dar, und zeigen Sie die Struktur, die der Vertrieb schon kennt. Ein Account mit einem untergeordneten Datensatz pro ERP setzt einen Auftraggeber voraus, der die gemeinsamen Werte synchron hält. Lesen Sie noch einmal Fragen Sie, wie die ERPs synchron gehalten werden.

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.
• Der Abschnitt Weiterlesen jedes Moduls nennt die Salesforce-Dokumentation hinter seinen Fakten, mit dem Prüfdatum.