Datamodellen er skelettet
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)
Modul 2 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Tænk som en arkitekt · Næste: Reversibilitetstesten
Spørgsmålet, dette modul besvarer: Hvorfor betyder datamodellen mere end alt det, der bygges oven på den, og hvordan vurderer du en?
Når jeg underviser i dataarkitektur, er der en sætning, jeg vender tilbage til igen og igen: datamodellen er skelettet.
Datamodellen er systemets skelet. Alt andet bygges omkring den, og det er den, der holder resten af kroppen sammen. Du ser ikke skelettet, når du kigger på en person, men det bestemmer, hvor rank personen står, hvordan personen bevæger sig, og hvad personen kan bære.
Tænk på alt det, vi bygger i en Salesforce-implementering. Vi bygger automatisering omkring datamodellen. Vi skriver Apex mod den og Flows, der læser og opdaterer den. Vi bygger integrationer, der sender data ind i den og henter data ud af den. Vi laver rapporter og analyser på den, og vi designer sikkerhed omkring den. Og i stigende grad bygger vi AI-agenter, der skal forstå de data og handle på dem. Det hele afhænger af strukturen nedenunder.
Derfor betyder det så meget at få datamodellen rigtig tidligt. Du kan godt ændre skelettet senere. Men det kommer nok til at gøre ondt.
Start med forretningen
Sektion kaldt “Start med forretningen ”En god datamodel starter med et enkelt spørgsmål: hvad har forretningen egentlig brug for at repræsentere? Ikke »hvilke Salesforce-objekter har vi?« Og bestemt ikke »hvad kan jeg bygge hurtigt?«
Vi prøver at forstå forretningen først. Hvad er de vigtige ting i denne forretning? Hvordan hænger de sammen? Hvem ejer dem? Hvordan ændrer de sig over tid? Hvad skal huskes, og hvad deles på tværs af forretningsprocesser? Først når vi forstår de ting, skal vi begynde at oversætte dem til objekter, felter og relationer.
Det lyder indlysende. I praksis er det meget nemt at gøre det baglæns. Nogen genkender noget, der ligner en salgsmulighed (Opportunity), en sag (Case) eller et aktiv (Asset), og begynder straks at designe omkring det. Nogle gange er det præcis rigtigt. Andre gange prøver vi at presse en firkantet pind ned i et rundt hul, og når der først er bygget nok omkring den beslutning, bliver det meget dyrt at få pinden ud igen.
Her er et spørgsmål, jeg hører hele tiden. En kundes forretning kan have mange leveringsadresser. Skal hver adresse være en konto (Account) eller et brugerdefineret objekt? Før du svarer, så læg mærke til, hvad du først skal vide: hvad en adresse betyder for denne forretning, og hvad der sker med den. Det er at modellere forretningen før objekterne. (Du får mit svar i kapitel 3.)
Bære. Vokse. Yde.
Sektion kaldt “Bære. Vokse. Yde. ”Når jeg kigger på en datamodel, vil jeg have, at den består tre test: bære forretningen, vokse med forretningen og yde.
Bære. Modellen skal bære det, forretningen faktisk prøver at opnå. Der er stor forskel på en model, der teknisk set kan gemme dataene, og en model, der faktisk repræsenterer forretningen godt. Hvis jeg hele tiden tilføjer mærkelige felter, særlige flag, kompliceret automatisering og undtagelser, fordi modellen ikke helt passer, begynder jeg at spørge, om problemet virkelig er automatiseringen. Måske er modellen forkert. En god model skal gøre forretningen nemmere at forstå, ikke sværere.
Vokse. Når jeg siger vokse, mener jeg ikke kun flere poster. Volumen betyder noget: ti tusind poster og hundrede millioner skaber meget forskellige problemer. Men virksomheder vokser også i kompleksitet. De tilføjer produkter, går ind på nye markeder, opkøber virksomheder, ændrer processer, tilføjer kanaler og forbinder nye systemer. De opdager, at noget, de troede var én ting, i virkeligheden er fem forskellige ting. En model, der fungerer smukt i dag, kan blive en fælde, hvis der ikke er plads til i morgen. Derfor foretrækker jeg designs, der vokser ved tilføjelse, frem for designs, der hele tiden ændrer det, der allerede findes. Det er som regel nemmere at tilføje noget nyt end at omdefinere noget, som snesevis af andre ting afhænger af.
Yde. Data ligger ikke bare stille. Vi skriver dem, finder dem, forespørger på dem, deler dem, rapporterer på dem og integrerer dem, og i stigende grad henter AI-systemer dem som kontekst, før de handler. En model kan se smuk ud på et diagram og alligevel være forfærdelig at drive. Så vi designer både til hvordan dataene gemmes, og hvordan dataene skal bruges.
Og den skal blive ved med at yde. Den skal yde i stor skala: når antallet af brugere stiger, når datamængden stiger, under virkelige forhold og ved spidsbelastningerne, på årets travleste dag snarere end en gennemsnitlig dag. Og den skal blive ved med at yde, når noget uventet sker.
Bære. Vokse. Yde. Vi vender tilbage til de tre test gennem hele kurset.
For flad, for kompliceret eller bare forkert
Sektion kaldt “For flad, for kompliceret eller bare forkert ”Jeg har set datamodeller gå galt på tre måder.
Den første er at vælge den forkerte ting fra starten. Vi bruger et standardobjekt, fordi det ser tæt nok på ud, og bruger så år på at tilføje undtagelser, fordi det aldrig passede rigtigt. Det er den firkantede pind.
Den anden er at gøre modellen for flad. Alt kommer i ét objekt, og i starten virker det vidunderligt enkelt. Så vokser forretningen, og vi opdager, at nogle af tingene har deres egen livscyklus, kan forekomme flere gange, har brug for deres egen sikkerhed eller har deres egne relationer. Lige pludselig repræsenterer vi en en-til-mange-relation med Felt 1, Felt 2 og Felt 3 eller med stadig mere komplicerede flag og automatisering. Modellen gav os ikke plads til at vokse.
Den tredje er den modsatte fejl: vi overnormaliserer. Vi laver et elegant diagram med objekt efter objekt, hvor hvert begreb er perfekt adskilt. Teknisk smukt, praktisk elendigt. Brugerne har svært ved at forstå det, og sidelayouts og Lightning-sider med den ene relaterede liste efter den anden kan begynde at føles uendeligt dybe. Forespørgsler bliver mere komplicerede, automatisering krydser flere relationer, rapportering bliver sværere, og platformen skal arbejde mere for at besvare helt almindelige forretningsspørgsmål.
Så hvad er det rigtige, flad eller normaliseret? Der er ingen formel. Du har et billede af den optimale model i hovedet og forstår afvejningerne, efterhånden som du bevæger dig væk fra den. Det er arkitekturens kunst, og vi vender tilbage til det i modul 4 og i næste kapitel, hvor vi lærer at modellere. Indtil videre skal du bare se, at selve strukturen er en arkitektonisk beslutning.
Vær forsigtig med at ændre skelettet
Sektion kaldt “Vær forsigtig med at ændre skelettet ”Når et system først kører, bliver jeg meget forsigtig med grundlæggende ændringer i datamodellen.
Forestil dig, at et tekstfelt har eksisteret i årevis, og nogen siger: »Vi bruger det ikke rigtig på den måde længere. Lad os lave det om til et tal.« Det lyder som en feltændring. Men hvad afhænger af det felt? Flows, Apex, rapporter, integrationer, datapipelines, eksterne applikationer, AI-agenter. Og hvad sker der med de historiske data? Platformen lader dig ikke engang ændre et felts type, så længe kode eller flows stadig refererer til det, og det fortæller dig, hvor langt ændringen rækker.
Nogle gange er det rigtige svar ikke at ændre det, der allerede findes. Afhængigt af hvor stor ændringen er, vil jeg hellere lave noget nyt, migrere bevidst og udfase den gamle struktur:
Tilføj frem for at ændre. Udfas frem for at overraske.
Salesforce giver dig endda en måde at sige det på i metadataene: et felts Field Usage (feltbrug) kan sættes til DeprecateCandidate, »planned for deprecation and no longer in use« (planlagt til udfasning og ikke længere i brug). Det markerer feltet for alle, der læser objektet; det skjuler ikke feltet, så at pensionere det er stadig en beslutning, du selv skal føre ud i livet.
For når andre dele af arkitekturen først afhænger af noget, kan det være langt farligere at ændre dets betydning end at ændre dets navn. Den værste udgave er feltet, hvis navn forbliver det samme, mens indholdet ændrer sig: alt nedstrøms stoler stadig på navnet.
Selv noget så enkelt som at sætte flueben i Required (påkrævet) på et felt kan blive en tidsindstillet bombe. Hvis du allerede har indsamlet data, vil nogle poster ikke have feltet udfyldt. Så dage, uger eller måneder senere opdaterer nogen en af de poster, og gemningen fejler på grund af det påkrævede felt, og ingen har den værdi. En simpel ændring som at gøre et felt påkrævet kan få utilsigtede og forsinkede konsekvenser. Vi vender tilbage til Required, og til hvornår en værdi faktisk er kendt, i kapitel 3.
Ud over eksamen: AI bygger også på skelettet. Bed et AI-værktøj om at bygge en applikation, og det genererer objekterne, felterne, Flows, Apex, komponenterne og testene på få minutter. Hvis den oprindelige datamodel var forkert, har vi ikke undgået konsekvenserne af en dårlig beslutning; vi har fremskyndet dem, for hvert genereret lag er endnu en ting, der afhænger af den struktur. Derfor vil jeg have en menneskelig arkitekt, der gennemgår en AI-genereret datamodel, forstår den og står til ansvar for den. Modul 7 tager det et skridt videre.
Skelettet kommer først
Sektion kaldt “Skelettet kommer først ”Gennem kurset kommer vi til at tale om en masse teknologi: objekter og relationer, store datamængder, forespørgsler, integration, migrering, transaktioner, sikkerhed, Data 360 og AI. Under det hele ligger datamodellen.
Hvis modellen bærer forretningen, kan vokse med forretningen og yder til de måder, vi skal bruge dataene på, har vi bygget et stærkt fundament. Hvis vi får fundamentet forkert, bliver alt bagefter sværere.
Datamodellen er skelettet. Arkitekter skal være meget omhyggelige, når de designer skelettet. Ændringer i eksisterende strukturer kan få konsekvenser, der breder sig som ringe i vandet.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Om modellen bærer forretningen, kan vokse med den og yder til de måder, dataene skal bruges på.
- Om et begreb passer til et standardobjekt eller er en firkantet pind.
- Hvor flad eller hvor normaliseret modellen skal være, og hvorfor.
- Om en ændring i skelettet skal være en tilføjelse, en migrering eller en udfasning frem for en ændring på stedet.
Læs mere
Sektion kaldt “Læs mere ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-02; kontrolleret igen 2026-10-12): hvilke typeændringer der kan miste data, og hvorfor du ikke kan ændre typen på et felt, som Apex, flows eller processer refererer til.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-02; kontrolleret igen 2026-10-12): værdierne for Field Usage (Active, DeprecateCandidate, Hidden) og de øvrige klassifikationsfelter.