Datamodellen er skjelettet
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 2 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: Tenk som en arkitekt · Neste: Reversibilitetstesten
Spørsmålet denne modulen besvarer: Hvorfor betyr datamodellen mer enn alt som bygges på den, og hvordan vurderer du en?
Når jeg underviser i dataarkitektur, er det én formulering jeg kommer tilbake til igjen og igjen: datamodellen er skjelettet.
Datamodellen er skjelettet i systemet. Alt annet bygges rundt den, og det er den som holder resten av kroppen sammen. Du ser ikke skjelettet når du ser på noen, men det avgjør hvor høy personen er, hvordan personen beveger seg, og hva den kan bære.
Tenk på alt vi bygger i en Salesforce-implementering. Vi bygger automatisering rundt datamodellen. Vi skriver Apex mot den, og Flows som leser og oppdaterer den. Vi bygger integrasjoner som sender data inn i den og henter data ut av den. Vi lager rapporter og analyser på den, og vi designer sikkerhet rundt den. Og i økende grad bygger vi KI-agenter som må forstå og handle på de dataene. Alt sammen avhenger av strukturen under.
Derfor betyr det så mye å få datamodellen riktig tidlig. Du kan endre skjelettet senere. Men det kommer sannsynligvis til å gjøre vondt.
Start med virksomheten
Section titled “Start med virksomheten ”En god datamodell starter med et enkelt spørsmål: hva trenger virksomheten egentlig å representere? Ikke «hvilke Salesforce-objekter har vi?» Og absolutt ikke «hva kan jeg bygge raskt?»
Vi prøver å forstå virksomheten først. Hva er de viktige tingene i denne virksomheten? Hvordan henger de sammen? Hvem eier dem? Hvordan endrer de seg over tid? Hva må huskes, og hva deles på tvers av forretningsprosesser? Først når vi forstår det, bør vi begynne å oversette det til objekter, felt og relasjoner.
Dette høres selvsagt ut. I praksis er det veldig lett å gjøre det baklengs. Noen kjenner igjen noe som ligner på en salgsmulighet (Opportunity), en sak (Case) eller et aktivum (Asset), og begynner straks å designe rundt det. Noen ganger er det helt riktig. Andre ganger prøver vi å presse en firkantet kloss inn i et rundt hull, og når nok er bygget rundt den beslutningen, blir det svært dyrt å få klossen ut igjen.
Her er et spørsmål jeg hører hele tiden. En kunde kan ha mange leveringssteder. Bør hvert sted være en konto (Account), eller et egendefinert objekt? Før du svarer, legg merke til hva du må vite først: hva et sted betyr for denne virksomheten, og hva som skjer med det. Det er å modellere virksomheten før objektene. (Du får svaret mitt i kapittel 3.)
Bære. Vokse. Yte.
Section titled “Bære. Vokse. Yte. ”Når jeg ser på en datamodell, vil jeg at den skal bestå tre tester: bære virksomheten, vokse med virksomheten og yte.
Bære. Modellen må bære det virksomheten faktisk prøver å oppnå. Det er stor forskjell på en modell som teknisk sett kan lagre dataene, og en som faktisk representerer virksomheten godt. Hvis jeg hele tiden legger til rare felt, spesielle flagg, komplisert automatisering og unntak fordi modellen ikke helt passer, begynner jeg å spørre om problemet egentlig er automatiseringen. Kanskje er modellen feil. En god modell skal gjøre virksomheten lettere å forstå, ikke vanskeligere.
Vokse. Når jeg sier vokse, mener jeg ikke bare flere poster. Volum betyr noe: ti tusen poster og hundre millioner gir helt ulike problemer. Men virksomheter vokser også i kompleksitet. De legger til produkter, går inn i nye markeder, kjøper opp selskaper, endrer prosesser, legger til kanaler og kobler på nye systemer. De oppdager at noe de trodde var én ting, egentlig er fem forskjellige ting. En modell som fungerer nydelig i dag, kan bli en felle hvis det ikke er rom for i morgen. Derfor foretrekker jeg design som vokser ved å legge til, fremfor design som stadig endrer det som allerede finnes. Å legge til noe nytt er som regel enklere enn å omdefinere noe som dusinvis av andre ting avhenger av.
Yte. Data ligger ikke bare der. Vi skriver dem, finner dem, spør etter dem, deler dem, rapporterer på dem og integrerer dem, og i økende grad henter KI-systemer dem som kontekst før de handler. En modell kan se vakker ut i et diagram og likevel være forferdelig å drifte. Så vi designer for både hvordan dataene lagres og hvordan dataene skal brukes.
Og den må fortsette å yte. Den må yte i stor skala: når antall brukere øker, når datavolumet øker, under virkelige forhold og i toppene, på årets travleste dag og ikke en gjennomsnittlig dag. Og den må fortsette å yte når noe uventet skjer.
Bære. Vokse. Yte. Vi kommer tilbake til disse tre testene gjennom hele kurset.
For flat, for komplisert eller rett og slett feil
Section titled “For flat, for komplisert eller rett og slett feil ”Jeg har sett datamodeller gå galt på tre måter.
Den første er å velge feil ting fra starten. Vi bruker et standardobjekt fordi det ser nært nok ut, og bruker så år på å legge til unntak fordi det aldri passet. Det er den firkantede klossen.
Den andre er å gjøre modellen for flat. Alt havner i ett objekt, og i starten virker det fantastisk enkelt. Så vokser virksomheten, og vi oppdager at noen av tingene har sin egen livssyklus, kan forekomme flere ganger, trenger egen sikkerhet eller har egne relasjoner. Plutselig representerer vi en én-til-mange-relasjon med Felt 1, Felt 2 og Felt 3, eller med stadig mer kompliserte flagg og automatisering. Modellen ga oss ikke noe sted å vokse.
Den tredje er den motsatte feilen: vi overnormaliserer. Vi lager et elegant diagram med objekt etter objekt, der hvert begrep er perfekt adskilt. Teknisk vakkert, praktisk elendig. Brukerne sliter med å forstå det, og sideoppsettene og Lightning-sidene, med relatert liste etter relatert liste, kan begynne å føles endeløst dype. Spørringene blir mer kompliserte, automatiseringen krysser flere relasjoner, rapporteringen blir vanskeligere, og plattformen må jobbe mer for å svare på helt vanlige forretningsspørsmål.
Så hva er riktig, flatt eller normalisert? Det finnes ingen formel. Du har et bilde av den optimale modellen i hodet og forstår avveiningene etter hvert som du beveger deg bort fra den. Det er arkitekturens kunst, og vi kommer tilbake til den i modul 4 og i neste kapittel, der vi lærer å modellere. Foreløpig er det nok å se at selve strukturen er en arkitektonisk beslutning.
Vær forsiktig med å endre skjelettet
Section titled “Vær forsiktig med å endre skjelettet ”Når et system først er i drift, blir jeg veldig forsiktig med grunnleggende endringer i datamodellen.
Si at et tekstfelt har eksistert i årevis, og noen sier: «Vi bruker det egentlig ikke sånn lenger. La oss gjøre det om til et tall.» Det høres ut som en feltendring. Men hva avhenger av det feltet? Flows, Apex, rapporter, integrasjoner, datapipelines, eksterne applikasjoner, KI-agenter. Og hva skjer med de historiske dataene? Plattformen lar deg ikke engang endre typen på et felt mens kode eller flows fortsatt refererer til det, og det sier noe om hvor langt endringen rekker.
Noen ganger er det riktige svaret å ikke endre det som allerede finnes. Avhengig av hvor alvorlig endringen er, vil jeg heller lage noe nytt, migrere bevisst og fase ut den gamle strukturen:
Legg til i stedet for å endre. Fas ut i stedet for å overraske.
Salesforce gir deg til og med en måte å si det på i metadataene: et felts Field Usage (feltbruk) kan settes til DeprecateCandidate, «planlagt utfaset og ikke lenger i bruk». Det merker feltet for alle som leser objektet; det skjuler ikke feltet, så å pensjonere det er fortsatt en beslutning du må gjennomføre.
For når andre deler av arkitekturen først avhenger av noe, kan det være mye farligere å endre betydningen enn å endre navnet. Den verste varianten er feltet som beholder navnet mens innholdet endres: alt nedstrøms stoler fortsatt på navnet.
Selv noe så enkelt som å krysse av for Required (obligatorisk) på et felt kan bli en tidsinnstilt bombe. Hvis du allerede har samlet inn data, vil noen poster mangle verdi i det feltet. Så, dager, uker eller måneder senere, oppdaterer noen en av de postene, og lagringen feiler på grunn av det obligatoriske feltet, og ingen har den verdien. En enkel endring som å gjøre et felt obligatorisk kan få utilsiktede og forsinkede konsekvenser. Vi kommer tilbake til Required, og til når en verdi faktisk er kjent, i kapittel 3.
Utover eksamen: KI bygger også på skjelettet. Be et KI-verktøy bygge en applikasjon, og det genererer objektene, feltene, Flows, Apex, komponentene og testene på minutter. Hvis den opprinnelige datamodellen var feil, har vi ikke unngått konsekvensene av en dårlig beslutning; vi har fremskyndet dem, fordi hvert genererte lag er én ting til som avhenger av den strukturen. Derfor vil jeg at en menneskelig arkitekt skal gjennomgå en KI-generert datamodell, forstå den og stå ansvarlig for den. Modul 7 går videre med dette.
Skjelettet kommer først
Section titled “Skjelettet kommer først ”Gjennom kurset kommer vi til å snakke om mye teknologi: objekter og relasjoner, store datavolumer, spørringer, integrasjon, migrering, transaksjoner, sikkerhet, Data 360 og KI. Under alt sammen ligger datamodellen.
Hvis modellen bærer virksomheten, kan vokse med virksomheten og yter for måtene vi skal bruke dataene på, har vi bygget et solid fundament. Hvis vi får fundamentet feil, blir alt etterpå vanskeligere.
Datamodellen er skjelettet. Arkitekter bør være svært nøye når de designer skjelettet. Endringer i eksisterende strukturer kan få ringvirkninger.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Om modellen bærer virksomheten, kan vokse med den og yter for måtene dataene skal brukes på.
- Om et begrep passer i et standardobjekt eller er en firkantet kloss.
- Hvor flat eller hvor normalisert modellen skal være, og hvorfor.
- Om en endring i skjelettet bør være et tillegg, en migrering eller en utfasing, i stedet for en endring på stedet.
Les mer
Section titled “Les mer ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-02; kontrollert på nytt 2026-10-12): hvilke typeendringer som kan føre til tap av data, og hvorfor du ikke kan endre typen på et felt som Apex, flows eller prosesser refererer til.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-02; kontrollert på nytt 2026-10-12): verdiene for Field Usage (Active, DeprecateCandidate, Hidden) og de andre klassifiseringsfeltene.