Gjør modellen om til Salesforce
Finnes også på 28 språk
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 6 av 6 i kapitlet Modeller data for mening, kapittel 2 i kurset Data Architect. Hver modul står på egne ben. Forrige: Design til tredje normalform, og trekk deg så litt tilbake · Neste: studieguiden for kapitlet, deretter neste kapittel: Dataarkitektur i Salesforce
Spørsmålet denne modulen besvarer: Hvordan blir en logisk datamodell til en fysisk datamodell i Salesforce?
Endelig skal vi snakke om Salesforce. Hvis du har motstått trangen til å gjøre hver boks om til et objekt, kan du gjøre det nå. Men legg merke til rekkefølgen vi kom i: vi forsto virksomheten, beskrev dataene, plasserte hvert faktum der det hører hjemme, og bestemte hvor vi skulle bøye det med vilje. Først nå spør jeg hvordan Salesforce skal implementere det. Det er progresjonen jeg vil at du skal huske: konseptuell → logisk → fysisk. Den konseptuelle modellen beskriver virksomheten. Den logiske modellen beskriver dataene. Den fysiske modellen beskriver hvordan vi faktisk skal bygge det.
Sitt, bli, modellér
Section titled “Sitt, bli, modellér ”Det fysiske steget er lettest å se på noe lite, så kjæledyrene går først.
Hvem er virksomhetene og menneskene? Oppdretteren er en virksomhet, så den blir en konto (Account) med posttypen Oppdretter. Eieren er også en konto, eller en personkonto, med posttypen Eier. To varianter av det samme standardobjektet, side om side øverst i diagrammet, akkurat der de har stått siden modul 1.
Hva har ikke noe standardhjem? Kjæledyr, Rase, Triks, Kjæledyrtriks og Triksvurdering blir egendefinerte objekter. Og husker du arten vi kopierte over på kjæledyret i modul 5? Her får den jobben sin: den blir kjæledyrets posttype, Hund eller Katt. Ett objekt med to posttyper, hver med sitt eget sideoppsett og sine egne plukklisteverdier, i stedet for et Hund-objekt og et Katt-objekt.
Hvilke relasjoner er master-detail? Jeg bruker master-detail bare der det underordnede aldri får en ny overordnet. Et kjæledyrtriks hører til kjæledyret sitt hele livet, og hver triksvurdering hører til kjæledyrtrikset sitt, så begge er master-detail. Det lønner seg med en gang: det er master-detail som lar kjæledyret holde et sammendragsfelt (roll-up summary) over kjæledyrtriksene sine, så antallet Kjente triks fra modul 5 holder tritt av seg selv. Kjæledyr bytter derimot hjem, så Eier er en lookup.
Hvilke er lookup-relasjoner? Salesforce anbefaler ikke mer enn 10 000 underordnede poster på én overordnet. Et populært triks som Sitt, en vanlig rase eller en stor oppdretter kan lett passere det, så kjæledyrtrikset peker på trikset sitt med en lookup, og kjæledyret peker på rasen og oppdretteren sin på samme måte. Og unngå polymorfe relasjoner der du kan, den typen der ett felt kan peke på flere objekttyper. De er praktiske den første dagen og vanskeligere for alt som må lese dem senere: rapporter, integrasjoner og nå agenter.
Hva blir utenfor plattformen? Hvis kjæledyret har et GPS-halsbånd som rapporterer hvor det er, trenger den posisjonen ikke å kopieres inn i det hele tatt. Den kan være et eksternt objekt, lest direkte fra sporingssystemet til halsbåndet.
Hver beslutning i det diagrammet kan spores tilbake til noe vi bestemte tidligere, og det er poenget. Nå det samme steget for Steve Trucking.
Start med den logiske modellen
Section titled “Start med den logiske modellen ”Den logiske modellen vår for Steve Trucking inneholder nå detaljhandelspartner (Retail Partner), distribusjonssenter (Distribution Center), manifest, levering (Delivery), leveringslinje (Delivery Item), mottaker (Recipient), rute (Route), stopp (Stop), team (Crew), lastebil (Truck) og teamtildeling (Crew Assignment). Det er forretningsbegreper, og nå kan jeg begynne å koble dem til Salesforce.
En detaljhandelspartner kan være en konto (Account). En levering kan tilsvare noe Salesforce allerede har for planlagt arbeid ute i felten, eller den kan bli et egendefinert objekt. Et manifest har ingenting standard som passer, så det blir sannsynligvis egendefinert. Og mottakeren er et virkelig vanskelig spørsmål: en personkonto (Person Account), en kontakt (Contact), eller bare informasjon på leveringen? Det svarer vi ordentlig på i neste kapittel.
Det viktige ordet er fortsatt kan. Ikke anta implementeringen bare fordi et forretningsbegrep høres ut som et Salesforce-objekt. Det er derfor vi bygde den logiske modellen først: den gir oss noe å teste Salesforce-designet mot.
En forretningsentitet betyr ikke automatisk et egendefinert objekt
Section titled “En forretningsentitet betyr ikke automatisk et egendefinert objekt ”Her er en felle jeg vil at admins skal unngå: «Vi fant elleve entiteter, så vi trenger elleve egendefinerte objekter.» Nei. En logisk entitet forteller oss at forretningsbegrepet betyr noe. Den dikterer ikke hvordan Salesforce må lagre det. Et begrep kan bli et standardobjekt, et egendefinert objekt, en relasjon mellom objekter, et felt eller noen få felt, en verdi som forvaltes i konfigurasjonen, eller data som bor helt utenfor Salesforce (leveringsbildene til Steve Trucking er en god kandidat for det). Den fysiske modellen er der de valgene tas, og det er nettopp derfor vi ikke tok dem i den første samtalen.
Attributter blir fysiske felt
Section titled “Attributter blir fysiske felt ”Den samme overgangen skjer med attributter. Den logiske lastebilen vår har enhetsnummer, VIN, merke, modell, årsmodell, registreringsnummer og status. Nå bestemmer vi hvordan de finnes fysisk: hvilket objekt som eier dem, hvilke felttyper de bruker, hvilke som er obligatoriske, hvilke som må være unike, hvilke som er eksterne ID-er, hvilke som trenger validering, hvilke som avledes i stedet for å lagres, og hvilke som er sensitive. På det logiske nivået spurte vi hva en lastebil betyr. På det fysiske nivået spør vi hvordan Salesforce skal representere en lastebil. Forskjellige spørsmål.
Relasjoner blir plattformbeslutninger
Section titled “Relasjoner blir plattformbeslutninger ”All tiden vi brukte på relasjoner, lønner seg her. Vi vet allerede om hver av dem er én-til-én, én-til-mange eller mange-til-mange, påkrevd eller valgfri, og om historikken betyr noe. Nå bestemmer vi hvordan Salesforce implementerer den: en lookup, en master-detail eller et koblingsobjekt i Salesforce (Salesforce Junction Object), og kanskje et koblingsobjekt med egne attributter, fordi, som vi fant ut, selve relasjonen kan ha forretningsmessig betydning.
Tenk tilbake på teamtildelingen. Vi kunne ha startet dette kapitlet med å si: «La oss opprette et koblingsobjekt i Salesforce mellom team og lastebil.» Se hva vi da ville ha hoppet over: hvorfor relasjonen finnes, om den trenger en dato og en rute, om den har en status, og om et skadekrav uker senere trenger historikken. De forretningsspørsmålene forteller oss hva en teamtildeling er. Først da bør vi bestemme hvordan Salesforce bygger den, og om Salesforce allerede har noe som gjør jobben.
Tegn nå den fysiske modellen
Section titled “Tegn nå den fysiske modellen ”Diagrammet endrer seg igjen. Den konseptuelle modellen viste forretningsbegreper og enkle linjer. Den logiske modellen la til attributter, nøkler, kardinalitet og entitetene som gjemte seg i relasjoner. Nå begynner den fysiske modellen å se ut som Salesforce: standardobjekter, egendefinerte objekter, felt, relasjonstyper, og det som bor utenfor plattformen.
Jeg vil at du skal kunne legge de tre diagrammene side om side og se progresjonen: ikke tre urelaterte diagrammer, men den samme virksomheten på tre nivåer.
Et ord om hvordan jeg tegner disse, for oppsettet er en del av budskapet. Jeg plasserer hovedobjektet i midten, litt lavt. Hvis det har overordnede objekter, plasserer jeg dem litt over, slik at du leser modellen ovenfra og ned, fra venstre mot høyre, slik virksomheten tenker om den. Referansedata legges ut til siden. Farger betyr også noe: Salesforce gjør jeg alltid blå, og jeg velger en farge for selskapets egne systemer, vanligvis grønn, fordi grønn er en hyggelig og vennlig farge. Jeg bruker ikke rødt, og gule toner er litt harde. Når en modell er lagt opp slik, synger den for meg. Mange av diagrammene du finner, handler egentlig om plassforvaltning: hvordan parkerer jeg alle bilene mine i den overfylte garasjen? Jeg vil heller male et logisk bilde som hodet kan gripe.
Den fysiske modellen må respektere plattformen
Section titled “Den fysiske modellen må respektere plattformen ”Salesforce er ikke en generisk relasjonsdatabase. Den har meninger om relasjoner, eierskap, sikkerhet og rapportering. Den har grenser, spørreoppførsel og automatisering, og en arkitektur som påvirker hvordan en modell oppfører seg i stor skala. Så en logisk modell som ser perfekt ut på en tavle, kan måtte endres når den blir fysisk. Det er ikke Salesforce som står i veien. Det betyr at plattformen har en form, og gode arkitekter forstår den formen. Neste kapittel handler om akkurat det.
Noen ganger vil den fysiske modellen også med vilje avvike fra den rene logiske modellen på grunn av denormaliseringsbeslutningene vi tok i modul 5. Det er greit, så lenge vi kan forklare hvorfor.
Ikke design fra Setup
Section titled “Ikke design fra Setup ”Det er en vane jeg vil at du skal bryte hvis du har den: å starte dataarkitekturen din i Setup → Object Manager → New Custom Object og finne ut av modellen underveis. Salesforce gjør det utrolig lett å lage ting; det er en av styrkene, og en av grunnene til at svake datamodeller oppstår så fort. Noen klikk, og du har et objekt, noen til, og du har felt og en relasjon. Så kommer dataene, flows blir bygget, rapporter blir laget, integrasjoner blir avhengige av det, og objektet du laget på fem minutter, blir svært dyrt å endre. Det er reversibilitetstesten fra kapittel 1. Så før du klikker New Custom Object (nytt egendefinert objekt), tegn modellen.
Fysisk betyr ikke permanent
Section titled “Fysisk betyr ikke permanent ”Det er en annen grunn til at jeg holder de tre modellene adskilt: teknologien endrer seg. I dag bor noen av dataene til Steve Trucking på Salesforce core. I morgen kan en del av dem bo i Data 360, et datavarehus eller et system vi ikke har valgt ennå, og KI-assistenten (AI) trenger sin egen representasjon. Den fysiske arkitekturen kan endre seg, mens forretningsbegrepene holder seg bemerkelsesverdig stabile: detaljhandelspartnere, leveringer og mottakere finnes fortsatt. Det er det som gjør den logiske modellen verdifull. Den er en varig beskrivelse av virksomheten som ikke er bundet til dagens implementering.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”Når jeg gjør en logisk modell om til en fysisk Salesforce-modell, bestemmer jeg:
- Hvilke forretningsentiteter som tilsvarer standardfunksjonalitet i Salesforce, og hvilke som trenger egendefinerte objekter eller en annen representasjon.
- Hvordan logiske attributter blir fysiske felt, og hvordan relasjoner implementeres på plattformen.
- Hvor bevisst denormalisering hører hjemme i det fysiske designet.
- Hvilke data som hører hjemme på Salesforce, og hvilke som hører hjemme et annet sted.
- Hvilke egenskaper ved plattformen som krever at den fysiske modellen avviker fra den logiske.
Viktigst av alt: jeg vil kunne spore hver beslutning bakover. Hvis du peker på noe i den fysiske modellen min og spør «Hvorfor er det der?», bør jeg kunne ta deg tilbake gjennom den logiske modellen og den konseptuelle modellen til noe virksomheten faktisk trenger: virksomhet → konseptuell → logisk → fysisk.
Utover eksamen: hva KI endrer. KI kan nå ta et kravdokument helt fram til Salesforce-objekter og -felt i ett hopp. Det gjør rekkefølgen viktigere, ikke mindre viktig: hvis den hopper fra krav til konfigurasjon, be den vise hva som skjedde imellom: hva den bestemte var en entitet, hvilke nøkler den valgte, hvilke relasjoner den antok, og hvor den denormaliserte. Det er arkitekturbeslutninger, og arkitekten må fortsatt se dem.
Vi startet dette kapitlet i en første samtale, der vi lyttet etter substantiver, og vi avslutter det med en fysisk modell vi kan spore tilbake til virksomheten. Nå som vi har valgt å bygge på Salesforce, går neste spørsmål dypere: hva slags dataplattform bygger vi egentlig på?
Les mer
Section titled “Les mer ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (på engelsk, kontrollert 2026-10-02): «configure parent-child relationships with no more than 10,000 children to one parent record» (konfigurer relasjoner mellom overordnet og underordnet med høyst 10 000 underordnede per overordnet post). En retningslinje om data skew, ikke en absolutt grense; kapittel 7 går dypere.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-12): et sammendragsfelt (roll-up summary) teller eller summerer detaljposter gjennom en master-detail-relasjon.