Gør modellen til Salesforce

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 6 af 6 i kapitlet Modellér data for betydning, kapitel 2 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Design til tredje normalform, og træd så et skridt tilbage · Næste: kapitlets studieguide og derefter næste kapitel: Dataarkitektur i Salesforce

Spørgsmålet, dette modul besvarer: Hvordan bliver en logisk datamodel til en fysisk datamodel i Salesforce?

Endelig skal vi tale om Salesforce. Hvis du har modstået trangen til at gøre hver kasse til et objekt, må du gerne nu. Men læg mærke til den rækkefølge, vi kom i: vi forstod forretningen, beskrev dataene, placerede hver kendsgerning, hvor den hører hjemme, og besluttede, hvor vi med vilje ville bøje det. Først nu spørger jeg, hvordan Salesforce skal implementere det. Det er det forløb, jeg vil have dig til at huske: konceptuel → logisk → fysisk. Den konceptuelle model beskriver forretningen. Den logiske model beskriver dataene. Den fysiske model beskriver, hvordan vi faktisk vil bygge det.

Sit, bliv, modellér

Det fysiske skridt er lettest at se på noget lille, så kæledyrene kommer først.

Hvem er virksomhederne og menneskene? Opdrætteren er en virksomhed, så den bliver en konto (Account) med posttypen Opdrætter. Ejeren er også en konto, eller en personkonto, med posttypen Ejer. To slags af det samme standardobjekt, side om side øverst i diagrammet, lige der, hvor de har været siden modul 1.

Hvad har intet standardhjem? Kæledyr, Race, Trick, Kæledyrstrick og Trickvurdering bliver brugerdefinerede objekter. Og kan du huske den art, vi kopierede over på kæledyret i modul 5? Her får den sit job: den bliver kæledyrets posttype, Hund eller Kat. Ét objekt med to posttyper, hver med sit eget sidelayout og sine egne valglisteværdier, i stedet for et Hund-objekt og et Kat-objekt.

Hvilke relationer er master-detail? Jeg bruger kun master-detail, hvor barnet aldrig får en ny forælder. Et kæledyrstrick hører til sit kæledyr hele livet, og hver trickvurdering hører til sit kæledyrstrick, så begge er master-detail. Det betaler sig med det samme: master-detail er det, der lader kæledyret holde et oversigtsfelt (roll-up summary) over sine kæledyrstricks, så Kendte tricks-antallet fra modul 5 holder trit af sig selv. Kæledyr skifter dog hjem, så Ejer er en lookup-relation.

Hvilke er lookup-relationer? Salesforce anbefaler ikke mere end 10.000 børn på én forælder. Et populært trick som Sit, en almindelig race eller en stor opdrætter kan nemt komme over det, så Kæledyrstrick peger på sit Trick med en lookup-relation, og kæledyret peger på sin Race og sin Opdrætter på samme måde. Og undgå polymorfe relationer, hvor du kan, den slags hvor ét felt kan pege på flere objekttyper. De er praktiske på dag ét og sværere for alt, hvad der skal læse dem senere: rapporter, integrationer og nu agenter.

Hvad bliver uden for platformen? Hvis kæledyret har et GPS-halsbånd, der rapporterer, hvor det er, behøver den position slet ikke at blive kopieret ind. Den kan være et eksternt objekt, læst live fra halsbåndets sporingssystem.

Click to enlarge

Hver beslutning i det diagram kan føres tilbage til noget, vi besluttede tidligere, og det er pointen. Nu det samme skridt for Steve Trucking.

Start med den logiske model

Vores logiske model for Steve Trucking indeholder nu detailpartner, distributionscenter, manifest, levering, leveringslinje, modtager, rute, stop, team, lastbil og teamtildeling. Det er forretningsbegreber, og nu kan jeg begynde at mappe dem til Salesforce.

En detailpartner kunne være en konto. En levering kunne mappes til noget, Salesforce allerede har til planlagt arbejde i marken, eller den kunne blive et brugerdefineret objekt. Et manifest har intet standardobjekt, der passer, så det bliver sandsynligvis brugerdefineret. Og modtageren er et virkelig svært spørgsmål: en personkonto (Person Account), en kontakt (Contact) eller bare information på leveringen? Det besvarer vi ordentligt i næste kapitel.

Det vigtige ord er stadig kunne. Antag ikke implementeringen, bare fordi et forretningsbegreb lyder som et Salesforce-objekt. Derfor byggede vi den logiske model først: den giver os noget at teste designet i Salesforce op imod.

En forretningsentitet betyder ikke automatisk et brugerdefineret objekt

Her er en fælde, jeg gerne vil have admins til at undgå: »Vi har fundet elleve entiteter, så vi skal bruge elleve brugerdefinerede objekter.« Nej. En logisk entitet fortæller os, at forretningsbegrebet betyder noget. Den dikterer ikke, hvordan Salesforce skal gemme det. Et begreb kan blive et standardobjekt, et brugerdefineret objekt, en relation mellem objekter, et felt eller nogle få felter, en værdi, der administreres i konfigurationen, eller data, der bor helt uden for Salesforce (Steve Truckings leveringsbilleder er en god kandidat til det). Den fysiske model er der, hvor de valg bliver truffet, og det er præcis derfor, vi ikke traf dem i det første opkald.

Attributter bliver til fysiske felter

Den samme overgang sker med attributter. Vores logiske lastbil har et enhedsnummer, stelnummer (VIN), mærke, model, årgang, nummerplade og status. Nu beslutter vi, hvordan de fysisk skal findes: hvilket objekt der ejer dem, hvilke felttyper de bruger, hvilke der er påkrævede, hvilke der skal være unikke, hvilke der er eksterne id’er, hvilke der kræver validering, hvilke der udledes i stedet for at blive gemt, og hvilke der er følsomme. På det logiske niveau spurgte vi, hvad en lastbil betyder. På det fysiske niveau spørger vi, hvordan Salesforce vil repræsentere en lastbil. Forskellige spørgsmål.

Click to enlarge

Relationer bliver til platformsbeslutninger

Al den tid, vi brugte på relationer, betaler sig her. Vi ved allerede, om hver af dem er én-til-én, én-til-mange eller mange-til-mange, påkrævet eller valgfri, og om dens historik betyder noget. Nu beslutter vi, hvordan Salesforce implementerer den: en lookup-relation, en master-detail-relation eller et forbindelsesobjekt i Salesforce (Salesforce Junction Object), og måske en forbindelse med sine egne attributter, for som vi fandt ud af, kan selve relationen have forretningsmæssig betydning.

Tænk tilbage på teamtildelingen. Vi kunne have startet dette kapitel med at sige: »Lad os oprette et forbindelsesobjekt i Salesforce mellem team og lastbil.« Se, hvad vi så ville have sprunget over: hvorfor relationen findes, om den har brug for en dato og en rute, om den har en status, og om et skadeskrav uger senere har brug for dens historik. De forretningsspørgsmål fortæller os, hvad en teamtildeling er. Først derefter bør vi beslutte, hvordan Salesforce bygger den, og om Salesforce allerede har noget, der gør jobbet.

Tegn nu den fysiske model

Diagrammet ændrer sig igen. Den konceptuelle model viste forretningsbegreber og enkle streger. Den logiske model tilføjede attributter, nøgler, kardinalitet og de entiteter, der gemmer sig i relationer. Nu begynder den fysiske model at ligne Salesforce: standardobjekter, brugerdefinerede objekter, felter, relationstyper, og hvad der bor uden for platformen.

Click to enlarge

Jeg vil have, at du kan lægge de tre diagrammer side om side og se forløbet: ikke tre urelaterede diagrammer, men den samme forretning på tre niveauer.

Et ord om, hvordan jeg tegner dem, for layoutet er en del af budskabet. Jeg placerer det primære objekt i midten, lidt nede. Hvis det har overordnede objekter, placerer jeg dem lidt over, så du læser modellen oppefra og ned, fra venstre mod højre, sådan som forretningen tænker på den. Referencedata kommer ud til siden. Farver betyder også noget: Salesforce gør jeg altid blå, og jeg vælger en farve til virksomhedens egne systemer, som regel grøn, fordi grøn er en rar, venlig farve. Jeg bruger ikke rød, og gule nuancer er lidt hårde. Når en model er lagt ud sådan, synger den for mig. Mange af de diagrammer, du finder, handler i virkeligheden om pladsstyring: hvordan parkerer jeg alle mine biler i min overfyldte garage? Jeg vil hellere male et logisk billede, som hjernen kan forstå.

Den fysiske model skal respektere platformen

Salesforce er ikke en generisk relationsdatabase. Den har holdninger til relationer, ejerskab, sikkerhed og rapportering. Den har grænser, forespørgselsadfærd og automatisering og en arkitektur, der påvirker, hvordan en model opfører sig i stor skala. Så en logisk model, der ser perfekt ud på en tavle, skal måske ændres, når den bliver fysisk. Det er ikke Salesforce, der står i vejen. Det betyder, at platformen har en form, og gode arkitekter forstår den form. Det er præcis det, næste kapitel handler om.

Nogle gange vil den fysiske model også med vilje afvige fra den rene logiske model på grund af de denormaliseringsbeslutninger, vi traf i modul 5. Det er fint, så længe vi kan forklare hvorfor.

Design ikke ud fra Setup

Der er en vane, jeg gerne vil have dig til at bryde, hvis du har den: at starte din dataarkitektur i Setup → Object Manager → New Custom Object og finde ud af modellen undervejs. Salesforce gør det utrolig nemt at oprette ting; det er en af dens styrker og en af grundene til, at svage datamodeller opstår så hurtigt. Et par klik, og du har et objekt, et par til, og du har felter og en relation. Så kommer der data, flows bliver bygget, rapporter bliver oprettet, integrationer afhænger af det, og det objekt, du oprettede på fem minutter, er meget dyrt at ændre. Det er reversibilitetstesten fra kapitel 1. Så før du klikker på New Custom Object, så tegn modellen.

Fysisk betyder ikke permanent

Der er en anden grund til, at jeg holder de tre modeller adskilt: teknologien ændrer sig. I dag bor nogle af Steve Truckings data på Salesforce core. I morgen bor en del af dem måske i Data 360, et datavarehus eller et system, vi ikke har valgt endnu, og AI-assistenten har brug for sin egen gengivelse. Den fysiske arkitektur kan ændre sig, mens forretningsbegreberne forbliver bemærkelsesværdigt stabile: detailpartnere, leveringer og modtagere findes stadig. Det er det, der gør den logiske model værdifuld. Den er en holdbar beskrivelse af forretningen, som ikke er bundet til dagens implementering.

Hvad en arkitekt beslutter her

Når jeg gør en logisk model til en fysisk model i Salesforce, beslutter jeg:

• Hvilke forretningsentiteter der mappes til Salesforces standardfunktioner, og hvilke der har brug for brugerdefinerede objekter eller en anden repræsentation.
• Hvordan logiske attributter bliver til fysiske felter, og hvordan relationer implementeres på platformen.
• Hvor bevidst denormalisering hører hjemme i det fysiske design.
• Hvilke data der hører hjemme i Salesforce, og hvilke der hører hjemme et andet sted.
• Hvilke egenskaber ved platformen der kræver, at den fysiske model afviger fra den logiske.

Vigtigst af alt vil jeg kunne føre hver beslutning baglæns. Hvis du peger på noget i min fysiske model og spørger: »Hvorfor er det der?«, skal jeg kunne føre dig tilbage gennem den logiske model og den konceptuelle model til noget, forretningen faktisk har brug for: forretning → konceptuel → logisk → fysisk.

Ud over eksamen: hvad AI ændrer. AI kan nu tage et kravdokument hele vejen til Salesforce-objekter og -felter i ét hop. Det gør rækkefølgen vigtigere, ikke mindre vigtig: hvis den springer fra krav direkte til konfiguration, så bed den vise, hvad der skete ind imellem: hvad den besluttede var en entitet, hvilke nøgler den valgte, hvilke relationer den antog, og hvor den denormaliserede. Det er arkitekturbeslutninger, og arkitekten skal stadig se dem.

Vi startede dette kapitel i et første opkald, hvor vi lyttede efter navneord, og vi slutter det med en fysisk model, vi kan føre tilbage til forretningen. Nu hvor vi har valgt at bygge på Salesforce, går det næste spørgsmål dybere: hvilken slags dataplatform bygger vi egentlig på?

Læs mere

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (på engelsk, kontrolleret 2026-10-02): »konfigurér forælder-barn-relationer med højst 10.000 børn pr. overordnet post«. En retningslinje om data skew, ikke en hård grænse; kapitel 7 går dybere.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-12): et oversigtsfelt (roll-up summary) tæller eller summerer detaljeposter via en master-detail-relation.