Dette dokument giver en oversigt over ERD-notationerne (Salesforce Entity Relationship Diagram) og konventionerne for at hjælpe dig med at fortolke de produktdatamodeller, der er tilgængelige i datamodelgalleriet.

Et ERD, også kendt som en datamodel, er en grafisk repræsentation af et informationssystem. Den viser relationer mellem personer, objekter, steder, koncepter og begivenheder i dette system. Det er en logisk model, der overfører den funktionelle struktur af data. I Salesforce ERD'er tilknyttes enheder typisk til et objekt i Salesforce-databasen.

En enhed er en ting eller et objekt af betydning, hvad enten det er virkeligt eller konceptuelt, om hvilke oplysninger der skal kendes eller opbevares.

Enheder vises i diagrammerne som felter med afrundede hjørner. Hvert enhedsfelt indeholder typisk to betegnelser (hvor det er relevant):

• Enhedens logiske navn (f.eks. "Salesforce-enhed" i det eksempel, der vises her). Dette kan svare til entalsbetegnelsen for det repræsenterede Salesforce-objekt, men ikke altid.
• Det "fysiske" API-navn eller udviklernavn for objektet i din Salesforce-organisation (f.eks. "API-navn" i eksemplet). For administrerede pakkeobjekter inkluderer det API-navn, der er angivet i diagrammet, typisk ikke det administrerede pakkenavneområde ("vlocity_ins**", f.eks.), medmindre Salesforce- eller Branch-cloud'en bruger flere administrerede pakker. Slutningen af API-navnet for administrerede pakkeobjekter angiver typen af det anvendte tilpassede objekt: "**c" for almindelige tilpassede objekter og tilpassede indstillinger, "**mdt" for tilpassede metadata, "**x" for eksterne objekter.

Enhedsfelter kan også angive en eller flere attributter, der repræsenterer attributterne for denne enhed. En attribut efterfølges af enten et "#"- eller et "-"-tegn.

• En "#" angiver en attribut, der er en del af enhedens logiske entydige nøgle. I eksempeldiagrammet betragtes "Brugernøgleattribut" som enhedens primære brugernøgle.
• En "•" angiver en ikke-nøgleattribut.

Hvert enhedsrelationsdiagram illustrerer Salesforce-datamodellen fra perspektivet af en angivet cloud, f.eks. Sales Cloud, Service Cloud eller Marketing Cloud. Diagrammets farveskema afspejler clouden i fokus. Alle branchens clouds, f.eks. Financial Service Cloud, Health Cloud og Media Cloud, bruger samme farveskema for Branche.

Farven på en given enhed på diagrammet har også en specifik betydning. Fokus-cloud-farven angives ved brug af dens Salesforce-brandet farve, herunder nogle eksempler nedenfor.

Følgende afsnit gennemser de forskellige enhedsformatering, der refererer til Sales Cloud-eksempellæsningen nedenfor:

En enhed med farverne på focus-cloud'en repræsenterer et objekt, der leveres med licensen til den pågældende cloud.

En enhed med en hvid udfyldning og en sort kant repræsenterer et objekt, der leveres med en anden licens end fokuscloud, og som ikke er udvidet af fokuscloud-licensen. Konto- og kontaktenheder, der vises på f.eks. en Salgs- eller Service Cloud-ERD, vises som hvid med en sort kant, da disse objekter er tilgængelige med en platformslicens.

En enhed med en lysegrå udfyldning og en sort kant repræsenterer et objekt, der leveres med en anden licens end fokuscloud, men fokuscloud udvider dette objekt. Commerce Cloud udvider f.eks. basisobjektet Product2 med yderligere felter. Udvidelser inkluderer yderligere felter, relationer og registreringstyper.

Enheder uden grænser er virtuelle. Når de bruges i et diagram, bekræfter disse felter eksistensen af en enhed i den logiske model for domænet, men enheden implementeres ikke som et fysisk objekt i Salesforce. Dataene for denne enhed forventes at være tilgængelige via eksterne API-kald eller Salesforce Connect i den implementerede løsning.

Enheder med en stiplet kant oprettes som registreringstyper i Salesforce. I det eksempel, der vises her, har undertyperne Forretningskonto, Faktureringskonto, Forbrugerkonto og Servicekonto en stiplet kant, fordi de er tilknyttet registreringstyper, der leveres med den administrerede Communications Cloud-pakke.

Enheder med en punkteret kant er virtuelle. Hverken registreringstyper eller et separat objekt bruges til at skelne mellem disse undertyper i Salesforce-løsningen. Disse undertyper viser logisk et begreb fra det domæne, der hjælper med til at illustrere funktionaliteten af datamodellen.

En undertype af en enhed er definitionen af et undersæt af dens forekomster. Når der tilføjes et sæt af undertyper i en supertypeenhed, viser supertypeenheden de fælles attributter og relationer, mens undertypeenhederne viser attributter og relationer, der er specifikke for undertypen. I diagramnotationen udelukker undertyper hinanden, hvilket betyder, at enhver enkelt registrering skal være af en enkelt undertype.

Undertyper kan have indlejrede undertyper, der yderligere adskiller forekomsterne. Undertyper i diagrammerne er logiske, men de kan knyttes til en fysisk repræsentation på en af tre måder. Soliditeten af undertypeenhedskanten definerer, hvordan undertypen implementeres i Salesforce-datamodellen.

Undertypeenheder med en fast kant har et faktisk objekt, der sporer forekomsterne af denne undertype. I det eksempel, der vises her, har undertypen Ekstern bruger for Kontakt en solid kant, fordi Kontakter, der er registreret som eksterne brugere, spores med en registrering i objektet Bruger.

En relation er en navngivet, væsentlig tilknytning mellem to enheder.

Markeringerne og teksten på eller omkring linjerne beskriver kardinaliteten, valgfriheden og betydningen af relationen.

Kardinalitet angiver det relative antal forekomster på hver side af relationen. I notationen angiver slutningen af en relationslinje kardinaliteten af relationen i denne ende. En krans fod i en ende angiver, at mange enhedsforekomster i denne ende kan relateres til hver forekomst i den modsatte ende. Manglen på en krans fod i en ende angiver, at højst en enhedsforekomst i denne ende kan relateres til en given forekomst i den anden ende.

Salesforce understøtter to typer af relationsfelter: opslagsfelter og overordnet-underordnet-felter. Overordnet-underordnet-felter fungerer som påkrævede opslag, men de anvender yderligere tilknytning mellem de relaterede enheder. Registreringer på mange sider af relationen slettes overlappende, når den overordnede registrering slettes. Synligheden af detaljeregistreringerne styres også af synligheden af den overordnede registrering.

For at illustrere forskellen mellem en underordnet-overordnet-relation og en opslagsrelation låner Salesforce ERD'er diamantnotationen fra UML. En diamant på singularsiden af en relation betyder, at enheden på denne side spiller den overordnede rolle i relationen. Enheden på mange sider af en sådan relation er detaljen eller den underordnede enhed og kan tænkes som indeholdt i den overordnede enhed.

Valgfrihed angiver, om relationen er påkrævet eller ej for en forekomst i hver ende. Som et begreb er valgfrihed tæt relateret til kardinalitet, og notationen afspejler denne nærhed. Valgfrihed angives i hver afslutning af en relation gennem en cirkel eller søjle på tværs af linjen i den anden ende af relationen. Hvorfor i den anden ende af relationen? Hvis du vil inkludere valgmulighedsmarkeringen på den samme side af kurven som kardinaliteten.

På mange-siden (dvs. kransfod) af relationen er der næsten altid en cirkel på linjen. Dette betyder, at der kan være nul-til-mange-forekomster på den mange side af relationen for hver forekomst på den enkelte side af relationen.

På den entalside af relationen angiver en cirkel og en søjle en valgfri relation for enheden på kransens sidefod af relationen. Cirklen og søjlen betyder, at der kan være nul eller en forekomst på enkeltstående side af relationen for hver forekomst på mange sider.

Alternativt angiver dobbelte søjler på entalsiden af relationen en krævet relation for enheden på mange sider af relationen. Dobbeltlinjerne betyder, at der skal være en og kun en forekomst på den enkelte side af relationen for hver forekomst på den mange side.

Valgfriheden af en relation kan vises som påkrævet, selvom den underliggende fysiske relation i Salesforce er valgfri. F.eks. er feltet AccountId på Kontakt fysisk en valgfri relation, men hvis du ignorerer private kontakter, er den direkte relation mellem en kontakt og en konto logisk påkrævet. Indikatoren valgmulighed bruges sparsomt. I de fleste tilfælde afspejler den valgmulighed, der vises i ERD, relationens underliggende valgmulighed.

Udover kardinalitet og valgfrihed udtrykker hver relation mellem to enheder en bestemt betydning, der adskiller denne relation fra andre relationer mellem de samme to enheder. Relationens slutnavne, f.eks. "del af" og "oprettet af" i diagrammet ovenfor, definerer relationens karakter.

Når du kombinerer kardinalitet, valgfrihed og slutnavne for en relation, kan de bruges til at danne en sætning, der beskriver relationen.

Fra venstre mod højre: Hver (kan/skal) være <end name 1> (en og kun en / en eller flere) .

Fra højre mod venstre: Hver (kan/skal) være <end name 2> (en og kun en / en eller flere) .

F.eks.

Fra venstre mod højre: "Hver kontakt skal primært være en kontakt for en og kun en konto". Fra højre mod venstre: "Hver konto kan primært repræsenteres af en eller flere kontakter".

Relationslinjer er farvekodede. Relationer, der er tilføjet af clouden i fokus for diagrammet, tegnes i en farve. Sorte linjer repræsenterer en relation, der leveres med en anden licens end fokuscloud.

Relationer kan være mellem to forekomster af den samme enhed. Dette kaldes en rekursiv relation. En buet relationslinje bruges til at betegne rekursive relationer.

Salesforce ERD'er udelader typisk de fleste forretningsregler for at fokusere på datamodellens struktur, men en gensidig udeladende relation er en forretningsregel, der er informativ for strukturen, så den noteres. En gensidig udeladende relation angiver, at kun en af de flere relationer, der er inkluderet i arken, vil blive brugt til en given forekomst. Bemærk, at to, tre eller flere relationer kan deltage i den samme gensidigt udeladende relation. En sætning, der beskriver den gensidigt udeladende relation, der vises her, kan være: "Hver enhed kan være en forekomst af en og kun en Første anden enhed eller en og kun en Anden anden enhed".

Bemærk, at i Salesforce ERD'er er en brudt relationslinje, der passerer gennem buen, ikke en del af den gensidigt udeladende relation.

Officielle Salesforce-produkt-ERD'er følger layoutkonventioner for at forbedre læsbarheden. Disse layoutkonventioner inkluderer følgende:

• Relationslinjer skal altid være lige.
• Relationslinjer skal tegnes lodret eller vandret. I sjældne tilfælde, hvor dette ikke er muligt, skal du bruge en lige linje på en diagonal.
• For at bevare relationslinjer lige kan enhedsfelter ændres i størrelse (højere eller bredere) til at give en destination for relationerne mellem de to enheder. De mere vigtige enheder (der har flere relationer, der lander på dem) vises større på diagrammet, der styrker deres vigtighed.
• I løbet af en enkelt ERD skal kransens fod på relationer være ensartet på venstre side og/eller øverste side af relationslinjen (op-ned-layout) – eller ensartet på højre side og/eller nederste side af relationslinjen (højre-op-sidelayout). Denne konvention giver tydelighed, da den resulterer i ens enheder, der samles i det samme område af diagrammet, hvilket er nyttigt for at forstå enhederne. Brug af layoutet omvendt ned resulterer i diagrammer, der vises omvendt ned med underordnede enheder, der falder over eller til venstre for de overordnede enheder – men dette sikrer, at de mest specifikke enheder i diagrammet falder i diagrammets øverste venstre hjørne, hvilket gør diagrammerne mere synlige og genkendelige. Brug af layoutkonventionen fra højre side op resulterer i, at de samme fælles enheder falder øverst til venstre for hvert diagram, men de underordnede enheder vil være under eller til højre for de overordnede enheder.

Nøjagtig overholdelse af disse layoutkonventioner resulterer i et rent og nemt at læse diagram.

Sørg for at kontrollere datamodelgalleriet for de seneste Salesforce-datamodeller, der følger denne standard.