Dette dokumentet gir en oversikt over notasjonene og konvensjonene i Salesforces enhetsrelasjonsdiagram (ERD) for å hjelpe deg å tolke produktdatamodellene som er tilgjengelig i datamodellgalleriet, tydelig.
Et ERD, også kalt en datamodell, er en grafisk fremstilling av et informasjonssystem. Den viser relasjonene mellom personer, objekter, steder, konsepter og hendelser i dette systemet. Det er en logisk modell som overfører den funksjonelle strukturen til data. I Salesforce ERD-er tilordnes enheter vanligvis til et objekt i Salesforce-databasen.
En enhet er en ting eller et objekt av betydning, enten det er ekte eller konseptuelt, som informasjon må være kjent eller beholdt.
Enheter representeres i diagrammene som bokser med avrundede hjørner. Hver enhetsboks inneholder vanligvis to etiketter (der det er aktuelt):
- Det logiske navnet på enheten (for eksempel "Salesforce-enheten" i eksempelet som vises her). Dette kan tilsvare entallsetiketten til det representerte Salesforce-objektet, men ikke alltid.
- Det "fysiske" API-navnet eller utviklernavnet på objektet i Salesforce-organisasjonen (for eksempel "API-navn" i eksempelet). For administrerte pakkeobjekter inkluderer API-navnet som er oppført i diagrammet, vanligvis ikke navneområdet for den administrerte pakken ("vlocity_ins**", for eksempel), med mindre Salesforce- eller Bransje-skyen bruker flere administrerte pakker. Slutten på API-navnet for administrerte pakkeobjekter angir typen tilpasset objekt som brukes: **c for vanlige tilpassede objekter og tilpassede innstillinger, **mdt for tilpassede metadata, **x for eksterne objekter.
Enhetsbokser kan også vise ett eller flere attributter som representerer attributtene til denne enheten. Et attributt foregår av antingen #- eller --tegnet.
- En # angir et attributt som er en del av den logiske unike nøkkelen for enheten. I eksempeldiagrammet anses Brukernøkkelattributt som brukerens primærnøkkel for enheten.
- En "•" angir et ikke-nøkkelattributt.
Hvert enhetsrelasjonsdiagram illustrerer Salesforce-datamodellen fra perspektivet til en bestemt sky som Sales Cloud, Service Cloud eller Marketing Cloud. Fargeskjemaet i diagrammet gjenspeiler skyen i fokus. Alle skyer i bransjen, som Financial Service Cloud, Health Cloud og Media Cloud, bruker samme bransjefargeskjema.
Fargen på en gitt enhet i diagrammet har også en bestemt betydning. Fargen på fokusskyen angis med sin merkeprofilerte Salesforce-farge, inkludert noen eksempler nedenfor.
Følgende del vil se gjennom de forskjellige enhetsformateringene som refererer til Sales Cloud-eksempelheldingen nedenfor:
En enhet med fargene på fokusskyen representerer et objekt som leveres med lisensen for den skyen.
En enhet med hvitt utfylling og svart kantlinje representerer et objekt som leveres med en annen lisens enn fokusskyen, og som ikke utvides av fokusskylelisensen. Konto- og kontaktenheter som for eksempel vises i en Sales- eller Service Cloud ERD, vises som hvite med en svart kantlinje fordi disse objektene er tilgjengelige med en plattformlisens.
En enhet med en lys grå utfylling og en svart kantlinje representerer et objekt som leveres med en annen lisens enn fokusskyen, men fokusskyen utvider det objektet. Commerce Cloud utvider for eksempel basisobjektet Product2 med flere felt. Utvidelser inkluderer flere felt, relasjoner og posttyper.
Enheter uten grenser er virtuelle. Når disse boksene brukes i et diagram, bekrefter de eksistensen av en enhet i den logiske modellen for domenet, men enheten implementeres ikke som et fysisk objekt i Salesforce. Dataene for denne enheten forventes å få tilgang via eksterne API-kall eller Salesforce Connect i den distribuerte løsningen.
Enheter med en stiplet kantlinje modelleres som posttyper i Salesforce. I eksemplet som vises her, har undertypene Firmakonto, Faktureringskonto, Forbrukerkonto og Tjenestekonto en stiplet kantlinje fordi de tilordnes til posttyper som leveres med den administrerte pakken Communications Cloud.
Enheter med en perforert kantlinje er virtuelle. Verken posttyper eller et separat objekt brukes til å skille mellom disse undertypene i Salesforce-løsningen. Disse undertypene viser logisk et konsept fra domenet som bidrar til å illustrere funksjonaliteten til datamodellen.
En undertype av en enhet er definisjonen av et delsett av dens forekomster. Når et sett undertyper legges til i en supertypeenhet, viser supertypeenheten de felles attributtene og relasjonene, mens undertypeenhetene viser attributter og relasjoner spesifikke for undertypen. I diagramnotasjonen er undertyper gjensidig eksklusive, som betyr at alle enkeltposter må ha en enkelt undertype.
Undertyper kan ha nestede undertyper som skiller forekomstene ytterligere. Undertyper i diagrammene er logiske, men de kan tilordnes til en fysisk representasjon på en av tre måter. Soliditeten til enhetskantlinjen for undertypen definerer hvordan undertypen implementeres i Salesforce-datamodellen.
Undertypeenheter med en heltrukket kantlinje har et faktisk objekt som sporer forekomstene av denne undertypen. I eksemplet som vises her, har undertypen Ekstern bruker av Kontakt en solid kantlinje fordi kontakter som er registrert som eksterne brukere, spores med en post i Bruker-objektet.
En relasjon er en navngitt, betydelig tilknytning mellom to enheter.
Merkingen og teksten på eller rundt linjene beskriver kardinaliteten, valgfriheten og betydningen av relasjonen.
Kardinalitet angir det relative antall forekomster på hver side av relasjonen. I notasjonen angir ender av en relasjonslinje kardinaliteten til relasjonen på den enden. En krans bunn på en ende viser at mange enhetstilfeller på denne enden kan relateres til hver forekomst på den motsatte enden. Fraværet av en krans bunn på en ende indikerer at maksimalt én enhetstilfelle på den enden kan relateres til en gitt forekomst på den andre enden.
Salesforce støtter to typer relasjonsfelt: oppslagsfelt og overordnet-underordnet-detalj-felt. Overordnet-underordnet-felt er som nødvendige oppslag, men de bruker ekstra kobling mellom de relaterte enhetene. Poster på de mange sidene av relasjonen slettes gjennomgripende når den overordnede posten slettes. Synligheten til detaljpostene bestemmes også av synligheten til den overordnede posten.
For å illustrere forskjellen mellom en underordnet-overordnet-relasjon og en oppslagsrelasjon bruker Salesforce ERD-er diamantnotasjonen fra UML. En diamant på entallsiden av en relasjon betyr at enheten på den siden spiller den overordnede rollen i relasjonen. Enheten på den mange siden av en slik relasjon er detalj- eller underordnet enhet og kan tenkes som inneholdt i den overordnede enheten.
Valgfrihet angir om relasjonen er nødvendig eller ikke for en forekomst på hver ende. Som et konsept er valgfrihet nært relatert til kardinalitet, og notasjonen gjenspeiler denne nærheten. Valgfrihet angis ved hver ende av en relasjon gjennom en sirkel eller stolpe på tvers av linjen på den andre enden av relasjonen. Hvorfor på den andre enden av relasjonen? For å inkludere valgfrihetskoden på samme side av linjen som kardinaliteten.
På den mange (det vil si korfoten) siden av relasjonen er det nesten alltid en sirkel på linjen. Det betyr at det kan være null-til-mange-forekomster på den mange siden av relasjonen for hver forekomst på den entallsiden av relasjonen.
På entallsiden av relasjonen angir en sirkel og en stolpe en valgfri relasjon for enheten på kransens bunnside av relasjonen. Sirkelen og stolpen betyr at det kan være null eller én forekomst på entallsiden av relasjonen for hver forekomst på mange-siden.
På entallsiden av relasjonen kan du også bruke doble stolper til å angi en nødvendig relasjon for enheten på mange sider av relasjonen. Dobbeltstolpene betyr at det må være én og bare én forekomst på entallsiden av relasjonen for hver forekomst på mange-siden.
Valgfriheten til en relasjon kan vises som nødvendig selv om den underliggende fysiske relasjonen i Salesforce er valgfri. Feltet AccountId i Kontakt er for eksempel fysisk en valgfri relasjon, men hvis du ignorerer private kontakter, er den direkte relasjonen til en kontakt til en konto logisk nødvendig. Indikatoren for valgfrihet brukes sparsomt. I de fleste tilfeller gjenspeiler valgfriheten som vises i ERD, den underliggende valgfriheten til relasjonen.
Ut over kardinalitet og valgfrihet uttrykker hver relasjon mellom to enheter en bestemt betydning som skiller denne relasjonen fra andre relasjoner mellom de samme to enhetene. Relasjonssluttnavn, som "del av" og "bestående av" i diagrammet ovenfor, definerer relasjonens natur.
Når du kombinerer kardinaliteten, valgfriheten og sluttnavnene for en relasjon, kan de brukes til å danne en setning som beskriver relasjonen.
Fra venstre mot høyre: Hver
Fra høyre mot venstre: Hver
For eksempel:
Fra venstre mot høyre: "Hver kontakt må primært være en kontakt for én og bare én konto." Fra høyre mot venstre: "Hver konto kan primært representeres av én eller flere kontakter."
Relasjonslinjer er fargekodet. Relasjoner som legges til av skyen i fokus for diagrammet, tegnes med en farge. Svarte linjer representerer en relasjon som leveres med en annen lisens enn fokusskyen.
Relasjoner kan være mellom to forekomster av samme enhet. Dette kalles en rekursiv relasjon. En buet relasjonslinje brukes til å betegne rekursive relasjoner.
Salesforce ERD-er utelukker vanligvis de fleste forretningsregler for å fokusere på strukturen til datamodellen, men en gjensidig ekskluderende relasjon er én forretningsregel som er informativ for strukturen, så den noteres. En gjensidig ekskluderende relasjon angir at bare én av de flere relasjonene som er inkludert i arc-knappen, vil bli brukt til en gitt forekomst. Vær oppmerksom på at to, tre eller flere relasjoner kan delta i samme gjensidig eksklusive relasjon. En setning som beskriver den gjensidig eksklusive relasjonen som vises her, kan være: "Hver enhet kan være en forekomst av én og bare én Første annen enhet eller én og bare én Andre enhet."
Vær oppmerksom på at i Salesforce ERD-er er en brutt relasjonslinje som går gjennom buen, ikke en del av den gjensidig utelukkende relasjonen.
Offisielle Salesforce-produkt-ERD-er følger oppsettkonvensjoner for å forbedre lesbarheten. Disse oppsettkonvensjonene inkluderer følgende:
- Relasjonslinjer bør alltid være rette.
- Relasjonslinjer skal tegnes vertikalt eller horisontalt. I sjeldne tilfeller der dette ikke er mulig, bruker du en rett linje på en diagonal.
- For å holde relasjonslinjer rette kan enhetsboksene endres i størrelse (høyere eller bredere) for å gi et landingssted for relasjonene mellom de to enhetene. De viktigste enhetene (som har flere relasjoner som lander på dem) vises større i diagrammet, noe som styrker deres betydning.
- Gjennom en enkelt ERD bør kråken føtter på relasjoner være konsekvent på venstre side og/eller øvre side av relasjonslinjen (opp-ned-oppsett) – eller konsekvent på høyre side og/eller nedre side av relasjonslinjen (høyre-side-opp-oppsett). Denne konvensjonen gir klarhet fordi den fører til at lignende enheter samles i samme område av diagrammet, noe som er nyttig for å forstå enhetene. Bruk av oppad-ned-oppsettet fører til at diagrammer vises oppad-ned med underordnede enheter som faller over eller til venstre for overordnede enheter – men dette sikrer at de mest spesifikke enhetene i diagrammet faller øverst til venstre i diagrammet, noe som gjør diagrammene mer skille mellom hverandre og gjenkjennelige. Bruk av oppsettkonvensjonen på høyre side fører til at de samme felles enhetene faller øverst til venstre i hvert diagram, men underordnede enheter vil være nedenfor eller til høyre for overordnede enheter.
Nøye overholdelse av disse oppsettkonvensjonene fører til et rent og lettlesbart diagram.
Pass på å sjekke datamodellgalleriet for å finne de nyeste Salesforce-datamodellene som følger denne standarden.