Dit document biedt een overzicht van de notatie en conventies van Salesforce-entiteitsrelatiediagrammen (ERD's) om u te helpen de productgegevensmodellen die beschikbaar zijn in de galerie met gegevensmodellen, duidelijk te interpreteren.

Een ERD, ook wel gegevensmodel genoemd, is een grafische weergave van een informatiesysteem. Het toont de relaties tussen mensen, objecten, plaatsen, concepten en events in dat systeem. Het is een logisch model dat de functionele structuur van gegevens overbrengt. In Salesforce ERD's worden entiteiten doorgaans toegewezen aan een object in de Salesforce-database.

Een entiteit is een ding of object van betekenis, hetzij reëel of conceptueel, waarover informatie moet worden bekend of vastgehouden.

Entiteiten worden in de diagrammen weergegeven als vakken met afgeronde hoeken. Elk entiteitsvak biedt doorgaans twee labels (waar van toepassing):

• De logische naam van de entiteit (bijv. "Salesforce-entiteit" in het hier getoonde voorbeeld). Dit kan overeenkomen met het enkelvoudige label van het vertegenwoordigde Salesforce-object, maar niet altijd.
• De "fysieke" API-naam of Developer Name van het object in uw Salesforce-organisatie (bijv. "API-naam" in het voorbeeld). Voor beheerde pakketobjecten omvat de API-naam die in het diagram wordt vermeld, doorgaans niet de naamruimte van het beheerde pakket ("vlocity_ins**"), tenzij de Salesforce- of Industry-cloud meerdere beheerde pakketten gebruikt. Het einde van de API-naam voor beheerde pakketobjecten geeft het type aangepast object aan dat wordt gebruikt: "**c" voor reguliere aangepaste objecten en aangepaste instellingen, "**mdt" voor aangepaste metagegevens, "**x" voor externe objecten.

In entiteitsvakken kunnen ook een of meer kenmerken worden vermeld die representatief zijn voor de kenmerken van die entiteit. Een kenmerk wordt voorafgegaan door een "#"- of een "-"-teken.

• Een "#" geeft een kenmerk aan dat deel uitmaakt van de logische unieke sleutel van de entiteit. In het voorbeelddiagram wordt "Kenmerk van gebruikerssleutel" beschouwd als de primaire gebruikerssleutel van de entiteit.
• Een "•" geeft een niet-sleutelkenmerk aan.

Elk entiteitsrelatiediagram illustreert het Salesforce-gegevensmodel vanuit het perspectief van een opgegeven cloud, zoals Sales Cloud, Service Cloud of Marketing Cloud. Het kleurenschema van het diagram weerspiegelt de wolk in focus. Alle sectorclouds zoals Financial Service Cloud, Health Cloud en Media Cloud gebruiken hetzelfde kleurenschema voor de sector.

De kleur van een bepaalde entiteit in het diagram heeft ook een specifieke betekenis. De kleur van de focuswolk wordt aangegeven met behulp van de Salesforce-brandingkleur, waaronder enkele voorbeelden hieronder.

In de volgende sectie worden de verschillende entiteitsopmaak besproken die verwijst naar de onderstaande Sales Cloud-voorbeeldlegenda:

Een entiteit met de kleuren van de focuswolk vertegenwoordigt een object dat wordt geleverd met de licentie voor die cloud.

Een entiteit met een witte opvulling en zwarte rand vertegenwoordigt een object dat een andere licentie heeft dan de focuscloud en dat niet wordt uitgebreid door de focuscloudlicentie. Account- en contactpersoonsentiteiten die worden weergegeven in een Sales- of Service Cloud-ERD, worden bijvoorbeeld wit met een zwarte rand weergegeven, omdat die objecten beschikbaar zijn met een platformlicentie.

Een entiteit met een lichtgrijze opvulling en zwarte rand vertegenwoordigt een object dat een andere licentie heeft dan de focuswolk, maar de focuswolk breidt dat object uit. Zo breidt Commerce Cloud het basisobject Product2 uit met extra velden. Extensies omvatten extra velden, relaties en recordtypen.

Entiteiten zonder grenzen zijn virtueel. Bij gebruik in een diagram erkennen deze vakken het bestaan van een entiteit in het logische model voor het domein, maar wordt de entiteit niet geïmplementeerd als een fysiek object in Salesforce. De gegevens voor deze entiteit worden naar verwachting geopend via externe API-aanroepen of Salesforce Connect in de geïmplementeerde oplossing.

Entiteiten met een stippelrand worden in Salesforce gemodelleerd als recordtypen. In het hier getoonde voorbeeld hebben de subtypen Bedrijfsaccount, Factuuraccount, Consumentenaccount en Serviceaccount een stippelrand, omdat ze verwijzen naar recordtypen die worden geleverd met het beheerde pakket Communications Cloud.

Entiteiten met een stippelrand zijn virtueel. Recordtypen en een afzonderlijk object worden niet gebruikt om deze subtypen te onderscheiden in de Salesforce-oplossing. Deze subtypen geven logischerwijs een concept uit het domein weer dat de functionaliteit van het gegevensmodel helpt illustreren.

Een subtype van een entiteit is de definitie van een subset van zijn voorkomen. Wanneer een set subtypen wordt toegevoegd binnen een entiteit van het supertype, geeft de entiteit van het supertype de gemeenschappelijke kenmerken en relaties weer, terwijl de entiteiten van het subtype kenmerken en relaties tonen die specifiek zijn voor het subtype. In de diagramnotatie sluiten subtypen elkaar uit, wat betekent dat elke afzonderlijke record van één subtype moet zijn.

Subtypen kunnen geneste subtypen hebben die de voorkomens verder onderscheiden. Subtypen in de diagrammen zijn logisch, maar kunnen op een van de volgende drie manieren worden toegewezen aan een fysieke weergave. De soliditeit van de rand van de entiteit van het subtype bepaalt hoe het subtype wordt geïmplementeerd in het Salesforce-gegevensmodel.

Subtype-entiteiten met een vaste rand hebben een feitelijk object dat de voorkomens van dat subtype bijhoudt. In het hier getoonde voorbeeld heeft het subtype Externe gebruiker van Contactpersoon een stevige rand omdat contactpersonen die zijn geregistreerd als Externe gebruikers, worden bijgehouden met een record in het object Gebruiker.

Een relatie is een benoemde, significante koppeling tussen twee entiteiten.

De markeringen en tekst op of rond de lijnen beschrijven de kardinaliteit, de optionaliteit en de betekenis van de relatie.

Kardinaliteit geeft het relatieve aantal malen voorkomen aan elke zijde van de relatie aan. In de notatie geven de uiteinden van een relatielijn de kardinaliteit van de relatie aan dat einde aan. Een kraaienpootje aan een uiteinde geeft aan dat veel entiteitsvoorvallen aan dat uiteinde betrekking kunnen hebben op elk voorval aan het andere uiteinde. Het ontbreken van een kraaienpoot aan een uiteinde geeft aan dat maximaal één entiteitsvoorval aan dat uiteinde betrekking kan hebben op een bepaald voorval aan het andere uiteinde.

Salesforce ondersteunt twee soorten relatievelden: opzoekvelden en bovenliggende/onderliggende (ook bekend als hoofd-/detail) velden. Bovenliggende/onderliggende velden lijken op verplichte opzoekopdrachten, maar ze passen een extra koppeling toe tussen de gerelateerde entiteiten. Records aan de vele zijde van de relatie worden trapsgewijs verwijderd wanneer de bovenliggende record wordt verwijderd. Ook de zichtbaarheid van de detailrecords wordt bepaald door de zichtbaarheid van de bovenliggende record.

Ter illustratie van het verschil tussen een onderliggende-bovenliggende relatie en een opzoekrelatie lenen Salesforce ERD's de diamantnotatie van UML. Een diamant aan de enkelvoudige zijde van een relatie betekent dat de entiteit aan die zijde de hoofdrol in de relatie speelt. De entiteit aan de vele kant van een dergelijke relatie is het detail of de onderliggende entiteit en kan worden beschouwd als opgenomen in de bovenliggende entiteit.

Optionaliteit geeft aan of de relatie verplicht is of niet voor een voorval aan elk uiteinde. Als concept is optionaliteit nauw gerelateerd aan kardinaliteit en de notatie weerspiegelt die nabijheid. Optionaliteit wordt aan elk uiteinde van een relatie aangegeven door middel van een cirkel of staaf over de lijn aan het andere uiteinde van de relatie. Waarom aan de andere kant van de relatie? Als u de optionele mark-up wilt opnemen aan dezelfde kant van de lijn als de kardinaliteit.

Aan de vele (dat wil zeggen, kraaienpootje) kant van de relatie is er bijna altijd een cirkel op de lijn. Dit betekent dat er nul-op-veel voorvallen kunnen zijn aan de vele zijde van de relatie voor elk voorval aan de enkelvoudige zijde van de relatie.

Aan de enkelvoudige kant van de relatie geven een cirkel en een staaf een optionele relatie aan voor de entiteit aan de kraaienpootzijde van de relatie. De cirkel en de staaf betekenen dat er nul of één voorvallen kunnen zijn aan de enkelvoudige zijde van de relatie voor elk voorval aan de veelvoudige zijde.

Aan de enkelvoudige zijde van de relatie geven dubbele staven een verplichte relatie aan voor de entiteit aan de vele zijde van de relatie. De dubbele staven betekenen dat er één en slechts één voorkomen aan de enkelvoudige zijde van de relatie moet zijn voor elk voorkomen aan de veelvoudige zijde.

De optionaliteit van een relatie kan als verplicht worden getoond, ook al is de onderliggende fysieke relatie in Salesforce optioneel. Zo is het veld AccountId voor Contactpersoon fysiek een optionele relatie, maar als u Privécontactpersonen negeert, is de directe relatie van een Contactpersoon met een Account logischerwijs vereist. De optionaliteitsindicator wordt spaarzaam gebruikt. In de meeste gevallen weerspiegelt de optionaliteit die in het ERD wordt getoond, de onderliggende optionaliteit van de relatie.

Naast kardinaliteit en optionaliteit drukt elke relatie tussen twee entiteiten een bepaalde betekenis uit die die relatie onderscheidt van andere relaties tussen dezelfde twee entiteiten. Relatie-eindnamen, zoals "gedeelte van" en "waarvan" in het diagram hierboven, definiëren de aard van de relatie.

Wanneer u de kardinaliteit, optionaliteit en eindnamen van een relatie combineert, kunnen deze worden gebruikt om een zin te vormen die de relatie beschrijft.

Van links naar rechts: Elke (mag/moet) <eindnaam 1> zijn (één en slechts één/één of meer) .

Van rechts naar links: Elke (mag/moet) <eindnaam 2> zijn (één en slechts één/één of meer) .

Bijvoorbeeld:

Van links naar rechts: "Elke contactpersoon moet primair een contactpersoon voor één en slechts één account zijn." Van rechts naar links: "Elke account kan primair worden vertegenwoordigd door een of meer contactpersonen."

Relatielijnen zijn kleurgecodeerd. Relaties die zijn toegevoegd door de cloud en die de focus hebben op het diagram, worden in een kleur getekend. Zwarte lijnen vertegenwoordigen een relatie die een andere licentie heeft dan de focuswolk.

Relaties kunnen bestaan tussen twee voorkomens van dezelfde entiteit. Dit wordt een recursieve relatie genoemd. Een gebogen relatielijn wordt gebruikt om recursieve relaties aan te duiden.

Salesforce ERD's sluiten doorgaans de meeste bedrijfsregels uit om zich te richten op de structuur van het gegevensmodel, maar een wederzijds uitsluitende relatie is één bedrijfsregel die informatief is voor de structuur, zodat deze wordt vermeld. Een wederzijds-uitsluitende relatie geeft aan dat slechts één van de verschillende relaties die in de boog zijn opgenomen, voor een bepaald voorval wordt gebruikt. Vergeet niet dat twee, drie of meer relaties kunnen deelnemen aan dezelfde relatie die elkaar uitsluit. Een zin die de hier getoonde wederzijdse uitsluiting beschrijft, zou kunnen zijn: "Elke entiteit kan een instantie zijn van één en slechts één Eerste Andere Entiteit of één en slechts één Tweede Andere Entiteit."

Vergeet niet dat in de Salesforce ERD's een verbroken relatielijn die door de boog loopt, geen deel uitmaakt van de relatie die elkaar uitsluit.

Officiële ERD's van Salesforce-producten volgen lay-outconventies om de leesbaarheid te verbeteren. Deze lay-outconventies omvatten het volgende:

• Relatielijnen moeten altijd recht zijn.
• Relatielijnen moeten verticaal of horizontaal worden getekend. In zeldzame gevallen waarin dit niet mogelijk is, gebruikt u een rechte lijn op een diagonaal.
• Om relatielijnen recht te houden, kunnen entiteitsvakken worden aangepast (groter of breder) om een landingsplaats te bieden voor de relaties tussen de twee entiteiten. Hoe belangrijker entiteiten (waarop meer relaties landen) groter worden weergegeven in het diagram, wat hun belang versterkt.
• Gedurende één ERD moeten de kraaienpootjes voor relaties consistent links en/of bovenaan de relatielijn staan (lay-out ondersteboven) – of consistent rechts en/of onderaan de relatielijn (lay-out rechterzijde-omhoog). Deze conventie biedt duidelijkheid omdat het resulteert in soortgelijke entiteiten die zijn verzameld in hetzelfde gebied van het diagram, wat handig is voor het begrijpen van de entiteiten. Het gebruik van de lay-out Ondersteboven resulteert er wel in dat diagrammen ondersteboven worden weergegeven met onderliggende entiteiten die boven of links van bovenliggende entiteiten vallen – dit zorgt er echter voor dat de meest specifieke entiteiten in het diagram in de linkerbovenhoek van het diagram vallen, waardoor de diagrammen beter van elkaar te onderscheiden en te herkennen zijn. Het gebruik van de lay-outconventie rechts-omhoog resulteert in dezelfde gemeenschappelijke entiteiten die in de linkerbovenhoek van elk diagram vallen, maar onderliggende entiteiten komen onder of rechts van bovenliggende entiteiten te staan.

Nauwkeurige naleving van deze lay-outconventies resulteert in een schoon en gemakkelijk leesbaar diagram.

Controleer de gegevensmodelgalerij voor de nieuwste Salesforce-gegevensmodellen die deze standaard volgen.