Detta dokument ger en översikt av notationen och konventioner för Salesforce enhetsrelationsdiagram (ERD) för att hjälpa dig att tydligt tolka de produktdatamodeller som finns i datamodellgalleriet.

En ERD, även kallad datamodell, är en grafisk representation av ett informationssystem. Den visar relationerna mellan personer, objekt, platser, koncept och händelser i det systemet. Det är en logisk modell som förmedlar den funktionella strukturen för data. I Salesforce ERD mappar enheter vanligtvis till ett objekt i Salesforce-databasen.

En enhet är en sak eller ett objekt av betydelse, vare sig verklig eller konceptuell, om vilken information som behöver vara känd eller hållas.

Enheter representeras i diagrammen som rutor med rundade hörn. Varje enhetsruta har vanligtvis två etiketter (i förekommande fall):

• Enhetens logiska namn (t.ex. "Salesforce-enhet" i exemplet som visas här). Detta kan motsvara den enskilda etiketten för det representerade Salesforce-objektet, men inte alltid.
• Det "fysiska" API-namnet eller utvecklarnamnet på objektet i din Salesforce-organisation (t.ex. “API-namn” i exemplet). För objekt i hanterade paket inkluderar vanligtvis inte API-namnet som listas i diagrammet namnutrymmet för det hanterade paketet ("vlocity_ins**", till exempel) om inte Salesforce eller Industry Cloud använder flera hanterade paket. Slutet på API-namnet för hanterade paketobjekt anger vilken typ av eget objekt som används: “**c” för vanliga egna objekt och egna inställningar, “**mdt” för egna metadata, “**x” för externa objekt.

Enhetsrutor kan även lista ett eller flera attribut som är representativa för attributen för den enheten. Ett attribut föregås av antingen “#” eller “-”.

• Ett “#” indikerar ett attribut som är en del av enhetens logiska unika nyckel. I exempeldiagrammet anses "Användarnyckelattribut" vara användarens primära nyckel för enheten.
• Ett “•” indikerar ett icke-nyckelattribut.

Varje enhetsrelationsdiagram illustrerar Salesforce-datamodellen från perspektivet för ett specificerat moln som Sales Cloud, Service Cloud eller Marketing Cloud. Diagrammets färgschema återspeglar molnet i fokus. Alla branschmoln som Financial Service Cloud, Health Cloud och Media Cloud använder samma färgschema för Bransch.

Färgen på en given enhet i diagrammet har också en specifik betydelse. Fokusmolnets färg indikeras med dess Salesforce-varumärkta färg, inklusive några exempel nedan.

Följande avsnitt kommer att gå igenom den olika enhetsformateringen som refererar till Sales Cloud-exempelförklaringen nedan:

En enhet med samma färger som fokusmolnet representerar ett objekt som levereras med licensen för det molnet.

En enhet med en vit ifyllning och svart kant representerar ett objekt som levereras med en annan licens än Focus Cloud och som inte utökas av Focus Cloud-licensen. Konto- och kontaktenheter som visas på en Sales- eller Service Cloud ERD visas till exempel som vita med en svart kant eftersom dessa objekt är tillgängliga med en plattformslicens.

En enhet med en ljusgrå fyllning och svart kant representerar ett objekt som levereras med en annan licens än fokusmolnet, men fokusmolnet utökar objektet. Till exempel utökar Commerce Cloud basobjektet Product2 med ytterligare fält. Tillägg inkluderar ytterligare fält, relationer och posttyper.

Enheter utan gränser är virtuella. När de används i ett diagram erkänner dessa rutor existensen av en enhet i den logiska modellen för domänen, men enheten implementeras inte som ett fysiskt objekt i Salesforce. Data för denna enhet förväntas kommas åt via externa API-anrop eller Salesforce Connect i den distribuerade lösningen.

Enheter med en streckad kant modelleras som posttyper i Salesforce. I exemplet som visas här har undertyperna Företagskonto, Faktureringskonto, Konsumentkonto och Servicekonto en streckad kant eftersom de mappar till posttyper som levereras med det hanterade paketet Communications Cloud.

Enheter med en streckad kant är virtuella. Varken posttyper eller ett separat objekt används för att skilja mellan dessa undertyper i Salesforce-lösningen. Dessa undertyper visar logiskt ett koncept från domänen som hjälper till att illustrera funktionaliteten hos datamodellen.

En undertyp av en enhet är definitionen av en underuppsättning av dess förekomster. När en uppsättning undertyper läggs till inom en supertypenhet visar supertypenheten de gemensamma attributen och relationerna medan undertypenheterna visar attribut och relationer som är specifika för undertypen. I diagramnotationen utesluter undertyper varandra, vilket innebär att en enskild post måste vara av en enskild undertyp.

Undertyper kan ha kapslade undertyper som ytterligare skiljer förekomsterna åt. Undertyper i diagrammen är logiska men de kan mappa till en fysisk representation på ett av tre sätt. Soliditeten hos undertypens enhetsram definierar hur undertypen implementeras i Salesforce-datamodellen.

Undertypenheter med en hel kant har ett faktiskt objekt som följer förekomsterna av den undertypen. I exemplet som visas här har undertypen Extern användare av Kontakt en solid kant eftersom Kontakter som är registrerade som Externa användare spåras med en post i objektet Användare.

En relation är en namngiven, betydelsefull association mellan två enheter.

Markeringarna och texten på eller runt linjerna beskriver relationens kardinalitet, valfrihet och mening.

Kardinalitet indikerar det relativa antalet förekomster på varje sida av relationen. I notationen indikerar slutet av en relationslinje kardinaliteten för relationen i den änden. En kråkfot i en ände indikerar att många enhetsförekomster i den änden kan relatera till varje förekomst i motsatt ände. Avsaknaden av en kråkfot i en ände indikerar att högst en enhetsförekomst i den änden kan relatera till en given förekomst i den andra änden.

Salesforce har stöd för två typer av relationsfält: sökfält och överordnad-underordnad-fält (kallas huvud-detalj-fält). Överordnad-underordnad-fält är som obligatoriska sökningar men de tillämpar ytterligare koppling mellan de relaterade enheterna. Poster på många sidor av relationen tas bort i kaskad när den överordnade posten tas bort. Även synligheten för detaljposterna styrs av synligheten för den överordnade posten.

För att illustrera skillnaden mellan en underordnad-överordnad relation och en sökrelation lånar Salesforce ERD diamantnotationen från UML. En diamant på en relations singularsida innebär att enheten på den sidan spelar huvudrollen i relationen. Enheten på många sidor av en sådan relation är detaljen eller den underordnade enheten och kan tänkas finnas inom den överordnade enheten.

Alternativ indikerar om relationen krävs eller inte för en förekomst i varje ände. Som koncept är optionalitet nära relaterad till kardinalitet och notationen återspeglar denna närhet. Alternativ indikeras i varje ände av en relation genom en cirkel eller stapel över linjen i andra änden av relationen. Varför i andra änden av relationen? För att inkludera valfrihetspålägget på samma sida av linjen som kardinaliteten.

På den många (det vill säga kråkfot) sidan av relationen finns det nästan alltid en cirkel på linjen. Detta innebär att det kan finnas noll till många förekomster på många sidor av relationen för varje förekomst på den singulära sidan av relationen.

På singularsidan av relationen indikerar en cirkel och en stapel en valfri relation för enheten på kråkfotsidan av relationen. Cirkeln och stapeln innebär att det kan finnas noll eller en förekomst på singularsidan av relationen för varje förekomst på många sidor.

Alternativt på den singulära sidan av relationen indikerar dubbla staplar en obligatorisk relation för enheten på många sidor av relationen. De dubbla staplarna innebär att det måste finnas en och endast en förekomst på singularsidan av relationen för varje förekomst på många sidor.

Valfriheten för en relation kan visas som obligatorisk även om den underliggande fysiska relationen i Salesforce är valfri. Till exempel är fältet AccountId i Kontakt fysiskt en valfri relation, men om du ignorerar Privata kontakter krävs logiskt en direkt relation för en kontakt till ett konto. Tillvalsindikatorn används sparsamt. I de flesta fall återspeglar det tillval som visas i ERD den underliggande tillvalet i relationen.

Utöver kardinalitet och valfrihet uttrycker varje relation mellan två enheter en viss betydelse som skiljer relationen från andra relationer mellan samma två enheter. Relationens slutnamn, som "del av" och "bestående av" i diagrammet ovan, definierar relationens karaktär.

När du kombinerar kardinalitet, tillval och slutnamn för en relation kan de användas för att bilda en mening som beskriver relationen.

Från vänster till höger: Varje (kan/måste) vara <end name 1> (en och endast en/en eller flera) .

Från höger till vänster: Varje (kan/måste) vara <end name 2> (en och endast en/en eller flera) .

Till exempel:

Från vänster till höger: "Varje kontakt måste i första hand vara en kontakt för ett och endast ett konto." Från höger till vänster: “Varje konto kan i första hand representeras av en eller flera kontakter.”

Relationsrader är färgkodade. Relationer som läggs till av molnet i fokus för diagrammet ritas i en färg. Svarta linjer representerar en relation som levereras med en annan licens än fokusmolnet.

Relationer kan vara mellan två förekomster av samma enhet. Detta kallas en återkommande relation. En krökt relationslinje används för att ange återkommande relationer.

Salesforce ERD utesluter vanligtvis de flesta verksamhetsregler för att fokusera på datamodellens struktur, men en ömsesidigt uteslutande relation är en verksamhetsregel som är informativ för strukturen så det noteras. En ömsesidigt uteslutande relation indikerar att endast en av de flera relationerna som inkluderas i bågen kommer att användas för en given förekomst. Observera att två, tre eller flera relationer kan delta i samma ömsesidigt uteslutande relation. En mening som beskriver den ömsesidigt uteslutande relation som visas här kan vara: “Varje enhet kan vara en instans av en och endast en Första andra enhet eller en och endast en Andra andra enhet.”

Observera att i Salesforce ERD är en trasig relationslinje som går genom bågen inte en del av den ömsesidigt uteslutande relationen.

Officiella Salesforce-produkt-ERD:er följer layoutkonventioner för att förbättra läsbarheten. Dessa layoutkonventioner inkluderar följande:

• Relationslinjer ska alltid vara raka.
• Relationslinjer ska dras vertikalt eller horisontellt. I sällsynta fall där detta inte är möjligt, använd en rak linje på en diagonal.
• För att hålla relationslinjer raka kan enhetsrutor ändra storlek (längre eller bredare) för att ge en landningsplats för relationerna mellan de två enheterna. De viktigare enheterna (som har fler relationer som landar på dem) visas större i diagrammet vilket förstärker deras betydelse.
• Genom en enskild ERD ska kråkfötterna på relationer vara konsekvent på vänster och/eller översta sidan av relationslinjen (upp-och-ner-layout) – eller konsekvent på höger och/eller understa sidan av relationslinjen (höger-och-upp-layout). Denna konvention ger tydlighet eftersom den resulterar i liknande enheter samlade i samma område i diagrammet, vilket är användbart för att förstå enheterna. Att använda layouten upp och ner resulterar i att diagram visas upp och ner med underordnade enheter ovanför eller till vänster om överordnade enheter – detta säkerställer dock att de mest specifika enheterna i diagrammet hamnar i diagrammets övre vänstra hörn, vilket gör diagrammen mer urskiljbara och lätta att känna igen. Att använda layoutkonventionen med höger och upp resulterar i att samma gemensamma enheter hamnar högst upp till vänster i varje diagram, men underordnade enheter hamnar under eller till höger om överordnade enheter.

Att följa dessa layoutkonventioner resulterar i ett rent och lättläst diagram.

Se till att kontrollera datamodellgalleriet för de senaste Salesforce-datamodellerna som följer denna standard.