Datamodellen är skelettet
Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 av 7 i kapitlet Tänk som en dataarkitekt, kapitel 1 i kursen Data Architect. Varje modul står på egna ben. Föregående: Tänk som en arkitekt · Nästa: Reversibilitetstestet
Frågan den här modulen besvarar: Varför spelar datamodellen större roll än allt som byggs på den, och hur bedömer du en?
När jag undervisar i dataarkitektur finns det en fras jag återkommer till om och om igen: datamodellen är skelettet.
Datamodellen är systemets skelett. Allt annat byggs runt det, och det är skelettet som håller ihop resten av kroppen. Du ser inte skelettet när du tittar på någon, men det avgör hur lång personen är, hur den rör sig och vad den orkar bära.
Tänk på allt vi bygger i en Salesforce-implementation. Vi bygger automatisering runt datamodellen. Vi skriver Apex mot den, och Flows som läser och uppdaterar den. Vi bygger integrationer som skickar in data i den och hämtar data ur den. Vi skapar rapporter och analyser på den, och vi designar säkerheten runt den. Och i allt högre grad bygger vi AI-agenter som behöver förstå och agera på de data. Allt det beror på strukturen därunder.
Det är därför det är så viktigt att få datamodellen rätt tidigt. Du kan ändra skelettet senare. Men det kommer troligen att göra ont.
Börja med verksamheten
Section titled “Börja med verksamheten ”En bra datamodell börjar med en enkel fråga: vad behöver verksamheten egentligen representera? Inte ”vilka Salesforce-objekt har vi?” Och absolut inte ”vad kan jag bygga snabbt?”
Vi försöker förstå verksamheten först. Vilka är de viktiga sakerna i den här verksamheten? Hur hänger de ihop? Vem äger dem? Hur förändras de över tid? Vad måste kommas ihåg, och vad delas mellan affärsprocesser? Först när vi förstår de sakerna ska vi börja översätta dem till objekt, fält och relationer.
Det låter självklart. I praktiken är det väldigt lätt att göra det baklänges. Någon känner igen något som ser ut som en affärsmöjlighet (Opportunity), ett ärende (Case) eller en tillgång (Asset) och börjar direkt designa runt det. Ibland är det precis rätt. Ibland försöker vi få in en fyrkantig kloss i ett runt hål, och när tillräckligt mycket har byggts runt det beslutet blir det väldigt dyrt att få ut klossen igen.
Här är en fråga jag hör hela tiden. En kunds verksamhet kan ha många leveransplatser. Ska varje plats vara ett konto (Account), eller ett anpassat objekt? Innan du svarar, lägg märke till vad du skulle behöva veta först: vad en plats betyder för den här verksamheten, och vad som händer med den. Det är att modellera verksamheten före objekten. (Jag ger dig mitt svar i kapitel 3.)
Bära. Växa. Prestera.
Section titled “Bära. Växa. Prestera. ”När jag tittar på en datamodell vill jag att den klarar tre test: bära verksamheten, växa med verksamheten och prestera.
Bära. Modellen måste bära det verksamheten faktiskt försöker åstadkomma. Det är stor skillnad på en modell som tekniskt kan lagra data och en som faktiskt representerar verksamheten väl. Om jag hela tiden lägger till konstiga fält, specialflaggor, komplicerad automatisering och undantag för att modellen inte riktigt passar, börjar jag fråga mig om problemet verkligen är automatiseringen. Kanske är modellen fel. En bra modell ska göra verksamheten lättare att förstå, inte svårare.
Växa. När jag säger växa menar jag inte bara fler poster. Volym spelar roll: tio tusen poster och hundra miljoner skapar väldigt olika problem. Men verksamheter växer också i komplexitet. De lägger till produkter, går in på nya marknader, köper upp företag, ändrar processer, lägger till kanaler och kopplar in nya system. De upptäcker att något de trodde var en sak egentligen är fem olika saker. En modell som fungerar fint i dag kan bli en fälla om det inte finns plats för i morgon. Därför föredrar jag designer som växer genom tillägg framför designer som hela tiden ändrar det som redan finns. Att lägga till något nytt är oftast enklare än att omdefiniera något som dussintals andra saker beror på.
Prestera. Data ligger inte bara still. Vi skriver dem, hittar dem, ställer frågor mot dem, delar dem, rapporterar på dem och integrerar dem, och i allt högre grad hämtar AI-system dem som kontext innan de agerar. En modell kan se vacker ut i ett diagram och ändå vara hemsk att driva. Så vi designar för både hur data lagras och hur data kommer att användas.
Och den måste fortsätta prestera. Den måste prestera i stor skala: när antalet användare ökar, när datavolymen ökar, under verkliga förhållanden och vid topparna, på årets mest hektiska dag snarare än en genomsnittlig. Och den måste fortsätta prestera när något oväntat händer.
Bära. Växa. Prestera. Vi kommer att återkomma till de tre testen genom hela kursen.
För platt, för komplicerad eller helt enkelt fel
Section titled “För platt, för komplicerad eller helt enkelt fel ”Jag har sett datamodeller gå fel på tre sätt.
Det första är att välja fel sak från början. Vi använder ett standardobjekt för att det ser tillräckligt nära ut, och ägnar sedan år åt att lägga till undantag för att det aldrig passade. Det är den fyrkantiga klossen.
Det andra är att göra modellen för platt. Allt hamnar i ett objekt, och först verkar det underbart enkelt. Sedan växer verksamheten, och vi upptäcker att en del av sakerna har sin egen livscykel, kan finnas i flera exemplar, behöver egen säkerhet eller har egna relationer. Plötsligt representerar vi en en-till-många-relation med Fält 1, Fält 2 och Fält 3, eller med allt krångligare flaggor och automatisering. Modellen lämnade inget utrymme för oss att växa.
Det tredje är det motsatta misstaget: vi övernormaliserar. Vi skapar ett elegant diagram med objekt efter objekt, där varje begrepp är perfekt separerat. Tekniskt vackert, praktiskt eländigt. Användarna har svårt att förstå det, och sidlayouterna och Lightning-sidorna, med relaterad lista efter relaterad lista, kan börja kännas oändligt djupa. Frågorna blir mer komplicerade, automatiseringen korsar fler relationer, rapporteringen blir svårare och plattformen gör mer arbete för att svara på vanliga affärsfrågor.
Så vilket är rätt, platt eller normaliserat? Det finns ingen formel. Du har en bild av den optimala modellen i huvudet och förstår avvägningarna när du rör dig bort från den. Det är arkitekturens konst, och vi återkommer till den i modul 4 och i nästa kapitel, där vi lär oss att modellera. För tillfället: inse att strukturen i sig är ett arkitektoniskt beslut.
Var försiktig med att ändra skelettet
Section titled “Var försiktig med att ändra skelettet ”När ett system väl är i drift blir jag mycket försiktig med grundläggande ändringar i datamodellen.
Anta att ett textfält har funnits i flera år, och någon säger: ”Vi använder det inte riktigt så längre. Vi gör om det till ett tal.” Det låter som en fältändring. Men vad beror på det fältet? Flows, Apex, rapporter, integrationer, datapipelines, externa applikationer, AI-agenter. Och vad händer med historiska data? Plattformen själv låter dig inte ändra ett fälts typ så länge kod eller flows fortfarande refererar till det, vilket säger dig hur långt ändringen når.
Ibland är rätt svar att inte ändra det som redan finns. Beroende på hur genomgripande ändringen är skapar jag hellre något nytt, migrerar medvetet och fasar ut den gamla strukturen:
Lägg till hellre än ändra. Fasa ut hellre än överraska.
Salesforce ger dig till och med ett sätt att säga det i metadata: ett fälts Field Usage (fältanvändning) kan sättas till DeprecateCandidate, ”planerat för utfasning och används inte längre”. Det markerar fältet för alla som läser objektet; det döljer inte fältet, så att pensionera det är fortfarande ett beslut som du genomför.
För när andra delar av arkitekturen väl beror på något kan det vara mycket farligare att ändra dess betydelse än att ändra dess namn. Den värsta varianten är fältet vars namn förblir detsamma medan innehållet ändras: allt nedströms litar fortfarande på namnet.
Till och med något så enkelt som att kryssa i rutan Required (obligatoriskt) på ett fält kan bli en tidsinställd bomb. Om du redan har samlat in data kommer en del poster inte att ha det fältet ifyllt. Sedan, dagar, veckor eller månader senare, uppdaterar någon en av de posterna, och sparandet misslyckas på grund av det obligatoriska fältet, och ingen har det värdet. En enkel ändring som att göra ett fält obligatoriskt kan få oavsiktliga och fördröjda konsekvenser. Vi återkommer till Required, och till när ett värde faktiskt är känt, i kapitel 3.
Bortom provet: AI bygger också på skelettet. Be ett AI-verktyg att bygga en applikation, så genererar det objekten, fälten, Flows, Apex, komponenterna och testerna på några minuter. Om den ursprungliga datamodellen var fel har vi inte undvikit konsekvenserna av ett dåligt beslut; vi har påskyndat dem, eftersom varje genererat lager är en sak till som beror på den strukturen. Därför vill jag att en mänsklig arkitekt granskar en AI-genererad datamodell, förstår den och står till svars för den. Modul 7 tar det här vidare.
Skelettet kommer först
Section titled “Skelettet kommer först ”Under kursens gång kommer vi att prata om mycket teknik: objekt och relationer, stora datavolymer, frågor, integration, migrering, transaktioner, säkerhet, Data 360 och AI. Under alltihop ligger datamodellen.
Om modellen bär verksamheten, kan växa med verksamheten och presterar för de sätt vi kommer att använda data på, har vi byggt en stark grund. Om vi får grunden fel blir allt därefter svårare.
Datamodellen är skelettet. Arkitekter ska vara mycket försiktiga när de designar skelettet. Att ändra befintliga strukturer kan få följdverkningar i kedja.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”- Om modellen bär verksamheten, kan växa med den och presterar för de sätt data kommer att användas på.
- Om ett begrepp passar ett standardobjekt eller är en fyrkantig kloss.
- Hur platt eller hur normaliserad modellen ska vara, och varför.
- Om en ändring i skelettet ska vara ett tillägg, en migrering eller en utfasning, snarare än en ändring på plats.
Utforska vidare
Section titled “Utforska vidare ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-02; kontrollerad igen 2026-10-12): vilka typändringar som kan förlora data, och varför du inte kan ändra typen på ett fält som Apex, flows eller processer refererar till.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-02; kontrollerad igen 2026-10-12): värdena för Field Usage (Active, DeprecateCandidate, Hidden) och de andra klassificeringsfälten.