Dieses Dokument bietet eine Übersicht über die Notation und Konventionen von Salesforce-Einheitenbeziehungsdiagrammen, damit Sie die in der Datenmodellgalerie verfügbaren Produktdatenmodelle klar interpretieren können.

Ein ERD, auch als Datenmodell bezeichnet, ist eine grafische Darstellung eines Informationssystems. Sie zeigt die Beziehungen zwischen Personen, Objekten, Orten, Konzepten und Ereignissen in diesem System an. Es handelt sich um ein logisches Modell, das die funktionale Struktur von Daten vermittelt. In Salesforce ERDs werden Einheiten in der Regel einem Objekt in der Salesforce-Datenbank zugeordnet.

Eine Einheit ist eine Sache oder ein Objekt von Bedeutung, unabhängig davon, ob es sich um eine reale oder konzeptionelle Einheit handelt, über die Informationen bekannt oder gespeichert werden müssen.

Einheiten werden in den Diagrammen als Kästchen mit abgerundeten Ecken dargestellt. Jedes Einheitenfeld enthält in der Regel zwei Bezeichnungen (sofern zutreffend):

• Der logische Name der Einheit (z. "Salesforce-Einheit" im hier gezeigten Beispiel). Dies kann der singulären Bezeichnung des dargestellten Salesforce-Objekts entsprechen, jedoch nicht immer.
• Der "physikalische" API-Name oder Entwicklername des Objekts in Ihrer Salesforce-Organisation (z. "API-Name" im Beispiel). Bei Objekten mit verwalteten Paketen enthält der im Diagramm aufgeführte API-Name in der Regel nicht den Namespace des verwalteten Pakets ("vlocity_ins**"), es sei denn, Salesforce oder Industry Cloud verwenden mehrere verwaltete Pakete. Das Ende des API-Namens für Objekte verwalteter Pakete gibt den Typ des verwendeten benutzerdefinierten Objekts an: "**c" für reguläre benutzerdefinierte Objekte und benutzerdefinierte Einstellungen, "**mdt" für benutzerdefinierte Metadaten und "**x" für externe Objekte.

Einheitenfelder können auch ein oder mehrere Attribute aufführen, die für die Attribute dieser Einheit repräsentativ sind. Einem Attribut wird entweder ein "#"- oder ein "-"-Zeichen vorangestellt.

• Ein "#" gibt ein Attribut an, das Teil des logischen eindeutigen Schlüssels der Einheit ist. Im Beispieldiagramm wird "Benutzerschlüsselattribut" als primärer Benutzerschlüssel der Einheit betrachtet.
• Ein "•" gibt ein Nicht-Schlüsselattribut an.

Jedes Einheitenbeziehungsdiagramm veranschaulicht das Salesforce-Datenmodell aus der Perspektive einer angegebenen Cloud wie Sales Cloud, Service Cloud oder Marketing Cloud. Das Farbschema des Diagramms spiegelt die Cloud im Fokus wider. Alle Branchen-Clouds wie Financial Service Cloud, Health Cloud und Media Cloud verwenden dasselbe Branchen-Farbschema.

Die Farbe einer bestimmten Einheit im Diagramm hat auch eine bestimmte Bedeutung. Die Fokuswolkenfarbe wird anhand der Salesforce-Branding-Farbe angegeben, einschließlich einiger Beispiele unten.

Im folgenden Abschnitt werden die verschiedenen Einheitenformatierungen anhand der folgenden Sales Cloud-Beispiellegende erläutert:

Eine Einheit mit den Farben der Fokus-Cloud stellt ein Objekt dar, das mit der Lizenz für diese Cloud geliefert wird.

Eine Einheit mit weißer Füllung und schwarzem Rahmen stellt ein Objekt dar, das über eine andere Lizenz als die Fokus-Cloud verfügt und nicht um die Fokus-Cloud-Lizenz erweitert wird. Account- und Kontakteinheiten, die beispielsweise in einem Sales- oder Service Cloud ERD-System angezeigt werden, werden weiß mit einem schwarzen Rahmen angezeigt, da diese Objekte mit einer Plattformlizenz verfügbar sind.

Eine Einheit mit hellgrauer Füllung und schwarzem Rahmen stellt ein Objekt dar, das über eine andere Lizenz als die Fokus-Cloud verfügt. Die Fokus-Cloud erweitert dieses Objekt jedoch. Beispielsweise erweitert Commerce Cloud das Basisobjekt "Product2" um zusätzliche Felder. Erweiterungen enthalten zusätzliche Felder, Beziehungen und Datensatztypen.

Einheiten ohne Grenzen sind virtuell. Wenn diese Kästchen in einem Diagramm verwendet werden, wird die Existenz einer Einheit im logischen Modell für die Domäne bestätigt, die Einheit wird jedoch nicht als physisches Objekt in Salesforce implementiert. Es wird erwartet, dass über externe API-Aufrufe oder Salesforce Connect in der bereitgestellten Lösung auf die Daten für diese Einheit zugegriffen wird.

Einheiten mit gestricheltem Rahmen werden in Salesforce als Datensatztypen modelliert. Im hier gezeigten Beispiel weisen die Untertypen "Geschäftsaccount", "Rechnungsstellungsaccount", "Verbraucheraccount" und "Serviceaccount" einen gestrichelten Rahmen auf, da sie Datensatztypen zugeordnet sind, die mit dem verwalteten Communications Cloud-Paket bereitgestellt werden.

Einheiten mit einem gepunkteten Rahmen sind virtuell. Weder Datensatztypen noch ein separates Objekt werden verwendet, um diese Untertypen in der Salesforce-Lösung zu unterscheiden. Diese Untertypen stellen logisch ein Konzept aus der Domäne dar, das die Funktionalität des Datenmodells veranschaulicht.

Ein Untertyp einer Einheit ist die Definition einer Teilmenge ihrer Vorkommen. Wenn ein Satz von Untertypen innerhalb einer Supertypeinheit hinzugefügt wird, zeigt die Supertypeinheit die allgemeinen Attribute und Beziehungen an, während die Untertypeinheiten Attribute und Beziehungen anzeigen, die für den Untertyp spezifisch sind. In der Diagrammnotation schließen sich Untertypen gegenseitig aus, d. h., jeder einzelne Datensatz muss einen einzelnen Untertyp aufweisen.

Untertypen können verschachtelte Untertypen aufweisen, die die Vorkommen weiter unterscheiden. Untertypen in den Diagrammen sind logisch, können jedoch auf eine von drei Arten einer physischen Darstellung zugeordnet werden. Die Solidität des Rahmens der Untertypeinheit bestimmt, wie der Untertyp im Salesforce-Datenmodell implementiert wird.

Untertypeinheiten mit durchgezogenem Rahmen verfügen über ein tatsächliches Objekt, das die Vorkommen dieses Untertyps verfolgt. Im hier gezeigten Beispiel weist der Untertyp "Externer Benutzer" einen durchgezogenen Rahmen auf, da Kontakte, die als externe Benutzer registriert sind, mit einem Datensatz im Benutzerobjekt verfolgt werden.

Eine Beziehung ist eine benannte, signifikante Zuordnung zwischen zwei Einheiten.

Die Markierungen und der Text in oder um die Zeilen beschreiben die Kardinalität, die Optionalität und die Bedeutung der Beziehung.

Kardinalität gibt die relative Anzahl der Vorkommnisse auf jeder Seite der Beziehung an. In der Notation geben die Enden einer Beziehungslinie die Kardinalität der Beziehung an diesem Ende an. Ein Krähenfuß an einem Ende gibt an, dass sich viele Einheitenvorkommen an diesem Ende auf jede Vorkommen am gegenüberliegenden Ende beziehen können. Das Fehlen eines Krähenfußes an einem Ende deutet darauf hin, dass sich höchstens eine Entität auf diesem Ende auf eine bestimmte Entität am anderen Ende beziehen kann.

Salesforce unterstützt zwei Arten von Beziehungsfeldern: Nachschlagefelder und Felder vom Typ "Über-/Unterordnung" (auch Master-Detail-Felder genannt). Über-/Unterordnungsfelder sind wie erforderliche Nachschlagefelder, sie wenden jedoch eine zusätzliche Kopplung zwischen den zugehörigen Einheiten an. Datensätze auf der vielen Seite der Beziehung werden kaskadenartig gelöscht, wenn der übergeordnete Datensatz gelöscht wird. Auch die Sichtbarkeit der Detaildatensätze wird durch die Sichtbarkeit des übergeordneten Datensatzes gesteuert.

Um den Unterschied zwischen einer untergeordneten und einer Nachschlagebeziehung zu veranschaulichen, entlehnen Salesforce ERDs die Diamantnotation aus UML. Ein Diamant auf der singulären Seite einer Beziehung bedeutet, dass die Einheit auf dieser Seite die Masterrolle in der Beziehung spielt. Die Entität auf der vielen Seite einer solchen Beziehung ist die Detail- oder untergeordnete Entität und kann als in der übergeordneten Entität enthalten angesehen werden.

Die Optionalität gibt an, ob die Beziehung für ein Auftreten an jedem Ende erforderlich ist oder nicht. Als Konzept ist die Optionalität eng mit der Kardinalität verbunden und die Schreibweise spiegelt diese Nähe wider. Die Optionalität wird an jedem Ende einer Beziehung durch einen Kreis oder Balken auf der anderen Seite der Beziehung angezeigt. Warum am anderen Ende der Beziehung? Um den optionalen Aufschlag auf derselben Seite der Linie wie die Kardinalität einzufügen.

Auf der vielen (d. h. Krähenfuß-) Seite der Beziehung befindet sich fast immer ein Kreis auf der Linie. Das bedeutet, dass es für jedes Auftreten auf der singulären Seite der Beziehung Null-zu-Viele-Vorkommen auf der vielen Seite der Beziehung geben kann.

Auf der singulären Seite der Beziehung geben ein Kreis und ein Balken eine optionale Beziehung für die Einheit auf der Krähenfußseite der Beziehung an. Der Kreis und der Balken bedeuten, dass es auf der singulären Seite der Beziehung für jedes Auftreten auf der vielen Seite null oder eins geben kann.

Alternativ können auf der singulären Seite der Beziehung doppelte Balken eine erforderliche Beziehung für die Einheit auf der vielen Seite der Beziehung angeben. Die doppelten Balken bedeuten, dass es für jedes Auftreten auf der vielen Seite ein und nur ein Auftreten auf der singulären Seite der Beziehung geben muss.

Die Optionalität einer Beziehung kann als erforderlich angezeigt werden, auch wenn die zugrunde liegende physische Beziehung in Salesforce optional ist. Beispielsweise ist das Feld AccountId für "Kontakt" physisch eine optionale Beziehung. Wenn Sie jedoch "Private Kontakte" ignorieren, ist die direkte Beziehung eines Kontakts zu einem Account logischerweise erforderlich. Die Optionalitätsanzeige wird sparsam verwendet. In den meisten Fällen spiegelt die im ERD angezeigte Optionalität die zugrunde liegende Optionalität der Beziehung wider.

Neben Kardinalität und Optionalität drückt jede Beziehung zwischen zwei Entitäten eine bestimmte Bedeutung aus, die diese Beziehung von anderen Beziehungen zwischen denselben beiden Entitäten unterscheidet. Beziehungsendnamen wie "Teil von" und "bestehen aus" im obigen Diagramm definieren die Art der Beziehung.

Wenn Sie Kardinalität, Optionalität und Endnamen einer Beziehung kombinieren, können sie verwendet werden, um einen Satz zu bilden, der die Beziehung beschreibt.

Von links nach rechts: Jeder (kann/muss) ist <Endname 1> (ein und nur ein / ein oder mehrere) .

Von rechts nach links: Jeder (kann/muss) ist <Endname 2> (ein und nur ein / ein oder mehrere) .

Beispiel:

Von links nach rechts: "Jeder Kontakt muss in erster Linie ein Kontakt für einen und nur einen Account sein." Von rechts nach links: "Jeder Account kann in erster Linie durch einen oder mehrere Kontakte dargestellt werden."

Beziehungslinien sind farbcodiert. Beziehungen, die von der Cloud im Fokus für das Diagramm hinzugefügt wurden, werden in einer Farbe gezeichnet. Schwarze Linien stellen eine Beziehung dar, die eine andere Lizenz als die Fokus-Cloud aufweist.

Beziehungen können zwischen zwei Vorkommen derselben Einheit bestehen. Dies wird als rekursive Beziehung bezeichnet. Eine gekrümmte Beziehungslinie wird verwendet, um rekursive Beziehungen anzugeben.

Salesforce ERDs schließen in der Regel die meisten Geschäftsregeln aus, um sich auf die Struktur des Datenmodells zu konzentrieren. Eine einander ausschließende Beziehung ist jedoch eine Geschäftsregel, die für die Struktur aussagekräftig ist. Eine einander ausschließende Beziehung gibt an, dass nur eine der verschiedenen im Arc enthaltenen Beziehungen für ein bestimmtes Auftreten verwendet wird. Beachten Sie, dass zwei, drei oder mehr Beziehungen an derselben einander ausschließenden Beziehung teilnehmen können. Ein Satz, der die hier gezeigte einander ausschließende Beziehung beschreibt, könnte wie folgt lauten: "Jede Einheit kann eine Instanz einer und nur einer ersten anderen Einheit oder einer und nur einer zweiten anderen Einheit sein."

Beachten Sie, dass in Salesforce ERDs eine unterbrochene Beziehungslinie, die durch den Bogen verläuft, nicht Teil der einander ausschließenden Beziehung ist.

Offizielle Salesforce-Produkt-ERDs folgen Layoutkonventionen, um die Lesbarkeit zu verbessern. Zu diesen Layoutkonventionen zählen:

• Beziehungslinien sollten immer gerade sein.
• Beziehungslinien sollten vertikal oder horizontal gezeichnet werden. In seltenen Fällen, in denen dies nicht möglich ist, verwenden Sie eine gerade Linie in einer Diagonalen.
• Um die Beziehungslinien gerade zu halten, können Einheitenboxen in ihrer Größe angepasst werden (größer oder breiter), um einen Zielort für die Beziehungen zwischen den beiden Einheiten bereitzustellen. Die wichtigeren Entitäten (auf denen mehr Beziehungen landen) werden im Diagramm größer angezeigt, was ihre Bedeutung unterstreicht.
• Bei einem einzelnen ERD sollten sich die Krähenfüße für Beziehungen konsistent auf der linken und/oder oberen Seite der Beziehungslinie befinden (Upside-down-Layout) – oder konsistent auf der rechten und/oder unteren Seite der Beziehungslinie (Right-side-up-Layout). Diese Konvention bietet Klarheit, da ähnliche Einheiten im selben Bereich des Diagramms gesammelt werden, was für das Verständnis der Einheiten hilfreich ist. Die Verwendung des auf dem Kopf stehenden Layouts führt zwar dazu, dass Diagramme auf dem Kopf stehen, wobei untergeordnete Entitäten oberhalb oder links von übergeordneten Entitäten angezeigt werden. Dadurch wird jedoch sichergestellt, dass sich die spezifischen Entitäten im Diagramm in der oberen linken Ecke des Diagramms befinden, wodurch die Diagramme besser voneinander zu unterscheiden und wiederzuerkennen sind. Die Verwendung der Layoutkonvention auf der rechten Seite führt dazu, dass dieselben gängigen Entitäten in jedem Diagramm oben links angezeigt werden, untergeordnete Entitäten jedoch unterhalb oder rechts von übergeordneten Entitäten.

Die genaue Einhaltung dieser Layoutkonventionen führt zu einem übersichtlichen und leicht lesbaren Diagramm.

Überprüfen Sie die Datenmodellgalerie auf die neuesten Salesforce-Datenmodelle, die diesem Standard entsprechen.