Design til tredje normalform, og trekk deg så litt tilbake

🌐 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)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 5 av 6 i kapitlet Modeller data for mening, kapittel 2 i kurset Data Architect. Hver modul står på egne ben. Forrige: Plasser data der de hører hjemme · Neste: Gjør modellen om til Salesforce

Spørsmålet denne modulen besvarer: Når bør jeg med vilje bevege meg bort fra en ren, normalisert modell?

I forrige modul sa jeg at du skulle designe for tredje normalform.

Nå skal jeg be deg bryte den.

Noen ganger.

Det er et viktig skille. Det er stor forskjell på å bygge en rotete datamodell ved et uhell og å denormalisere en ren modell med vilje. Hvis du ikke forstår hvor dataene hører hjemme i utgangspunktet, er det ikke arkitektur å kopiere dem et annet sted. Det er bare duplisering.

Men når jeg først forstår den rene logiske modellen, kan jeg ta en bevisst beslutning om å forme dataene annerledes for menneskene og systemene som bruker dem.

Design til tredje normalform der det er mulig. Trekk deg så tilbake når det er nødvendig.

Legg merke til hva den setningen ikke sier. Den sier ikke at tredje normalform er lettere å forstå. Noen ganger er den vanskeligere: en fullt normalisert modell kan spre én forretningsidé over fem objekter, og de som bruker den, må sette den sammen igjen i hodet. Normalisering forteller meg hvor hvert faktum hører hjemme. Den lover ikke at det er den letteste formen å lese, bruke eller rapportere på. Det er nettopp derfor det å trekke seg tilbake er en designferdighet og ikke et nederlag.

Start med å modellere sannheten. Bestem så hvordan den sannheten skal leveres.

Sitt, bli, modellér

Tilbake til hundene, og denne gangen tar vi noen bevisste valg.

Rase: en plukkliste, eller en egen tabell? Kjør den gjennom spørsmålene jeg gir deg senere i denne modulen. Er det mer enn én kolonne med informasjon? Ja: i hvert fall størrelsen. Hvor mange verdier? Kennelklubber anerkjenner noen hundre raser (American Kennel Club alene lister opp 205), langt over tommelfingerregelen min på rundt 20. Så Rase gjør seg fortjent til en egen tabell, og hver hund peker på rasen sin. Det avgjør spørsmålet vi har båret med oss siden modul 1: Rase er en egen boks.

Ferdighetsnivå: en plukkliste. Lærer, God, Ekspert. Tre etiketter, ingenting annet å si om dem, og de kommer ikke til å endre seg. Det er nettopp det en plukkliste er til for.

Hvor mange triks kan hver hund? Svaret ligger allerede i modellen: tell hundens Hundetriks-poster. Men treneren vil ha det tallet på hver rapport, for å sortere og filtrere på det, uten å bygge en rapport over to tabeller. Så jeg trekker meg tilbake og holder et antall Kjente triks rett på hunden. Det er en kopi. Sannheten bor fortsatt i Hundetriks; antallet er en representasjon av den, og det må holde tritt. Salesforce gir oss en ryddig måte å gjøre akkurat det på, og vi ser den i modul 6.

Så kommer vrien: hundeskolen begynner å ta imot katter. Hva gjør vi? Ett alternativ: legg til en Katt-tabell ved siden av Hund-tabellen, og et Kattetriks ved siden av Hundetriks. Alt dobles: to av hver skjerm, to av hver rapport, og den dagen de tar imot kaniner, tre. Det andre alternativet: ta et skritt tilbake og legg merke til at en katt har en eier, kanskje en oppdretter, en rase, en fødselsdato og, med tålmodighet, et triks eller to. De samme faktaene og de samme relasjonene som en hund. Så vi generaliserer: et Kjæledyr, med en Art, hund eller katt. Hver rase hører også til en art, og det er der arten egentlig bor: en labrador er en hund. Kjæledyret har en kopi, med vilje, slik at hver skjerm og hver rapport kan starte med «hund eller katt?» uten å slå opp rasen. Enda en bevisst kopi, og i modul 6 får den en egen jobb.

Det er å designe for endring, og det er en avveining. Generaliser for tidlig, så blir alt en vag «Ting» med et typefelt som ingen forstår. Jeg generaliserer når virksomheten faktisk kommer med den andre typen, og de to har nesten alt felles, slik hunder og katter har her. Hvis katter trengte helt andre fakta, ville jeg tenkt meg om to ganger.

Click to enlarge

Nå de samme typene valg hos Steve Trucking, der det står mer på spill.

Den reneste modellen er ikke alltid det beste systemet

Se for deg et team ved et stopp. Leveringen har sine varer. Installasjonen har en sjekkliste. Hvert steg trenger bilder. Mottakeren signerer.

Den normaliserte modellen er vakker: levering → leveringslinje → installasjonssjekkliste → bilde, hver der den hører hjemme.

Så setter jeg meg ned med dem som faktisk bruker den. Et team lukker rundt ti stopp om dagen, i oppkjørsler, ofte uten dekning. Hvis den vakre modellen min sender dem gjennom en labyrint av skjermer og relaterte lister for å fullføre ett stopp, har jeg et arkitekturproblem.

Datamodellen er ikke det eneste vi designer.

Vi designer et system.

Noen ganger vinner brukeropplevelsen

Dette er en av grunnene til at jeg noen ganger trekker meg bort fra en perfekt normalisert modell: brukeropplevelse.

Kanskje et begrep teknisk sett kunne vært en egen entitet, men å skille det ut gir kompleksitet som tilfører svært lite verdi. Kanskje en overordnet post med flere nivåer av underordnede er akademisk ren, men elendig å registrere og vedlikeholde. Kanskje begrepet er lite, stabilt og mest brukt som et valg i en liste.

Det er her jeg slutter å bare spørre «Hvor hører dette faktumet teoretisk hjemme?» og begynner å spørre «Hvordan kommer dette systemet faktisk til å bli brukt?»

Det betyr ikke at hver klage på et ekstra klikk flater ut modellen. Det betyr at brukervennlighet er et legitimt arkitektonisk innspill.

Noen ganger vinner rapporteringen

Rapportering er en annen vanlig grunn.

Hver detaljhandelspartner vil ha et resultatkort: leveringer i tide per region, per måned. I den rene modellen kjenner en levering distribusjonssenteret sitt, og DC-et kjenner regionen sin. Teknisk sett kan vi navigere det.

Men kan rapportverktøyet det? Kan de som bygger sine egne rapporter? Kan de svare på spørsmålet uten en rapportarkitektur som er mer komplisert enn selve spørsmålet?

Det er da jeg kanskje kopierer eller avleder regionen over på leveringen, nærmere der den brukes.

Nå har jeg innført duplisering. Så jeg trenger enda et spørsmål: hvem eier sannheten?

Hvis kildeverdien endres, hva skjer med kopien min? Skal den endres? Eller skal den beholde det som var sant da leveringen skjedde? Det er forskjellige krav.

Denormalisering fjerner ikke kompleksitet.

Den flytter den.

Lookup eller plukkliste?

Her er et mindre eksempel som Salesforce-admins møter hele tiden. Brukeren må velge fra et sett med verdier. Oppretter jeg en ny entitet og kobler til den, eller bruker jeg en plukkliste?

Ta statusen til en levering: planlagt, lastet, ute for levering, ankommer, levert, installert, avvik, returnert. En kort, stabil liste med etiketter. En plukkliste er nøyaktig det jeg vil ha.

Ta så typen stopp: bare levering, levering med installasjon, levering med bortkjøring. Den bærer egen informasjon: hvor lang tid stoppet tar, hvilke ferdigheter teamet trenger, hvilken installasjonssjekkliste som gjelder. Den endrer seg uavhengig, og virksomheten forvalter den. Det er en entitet, ikke en etikett.

Hvis jeg oppretter et objekt for hvert begrep som teoretisk kunne normaliseres, kan jeg bygge et teknisk vakkert system som ingen liker å bruke. Hvis jeg gjør hvert begrep om til en plukkliste fordi det er lett, kan jeg male meg inn i et hjørne veldig fort.

Så jeg spør: har den egen informasjon? Relasjoner? Endrer den seg uavhengig? Må den forvaltes som data? Kan virksomheten etter hvert trenge mer fra den enn en etikett?

Her er spørsmålene jeg faktisk stiller i en designøkt.

Er det mer enn én kolonne med informasjon? Hvis verdien trenger en beskrivelse, en varighet, en ferdighetsliste, en eier, er den ikke lenger en etikett.

Hvor mange verdier? Tommelfingerregelen min er rundt 20. Over 20 verdier begynner en plukkliste å bryte sammen, og det er på tide å tenke på et objekt. Delstater, femti av dem, er unntaket vi lever med, og land er verre; ærlig talt, er det noen som elsker plukklister med land? Jeg synes de er irriterende.

Opprettes verdiene over tid, og av hvem? Å legge til en verdi i en plukkliste er en konfigurasjonsendring, og det betyr en admin. Hvis virksomheten legger til verdier hver uke, og de som legger dem til, ikke er admins, setter en plukkliste en sak i køen foran hver nye verdi.

Trenger folk å filtrere og rapportere på den? Plukklister er gode til det. Lookup-relasjoner er ikke like ryddige. Hver lookup legger til et hopp: en rapporttype følger bare en kort kjede av relaterte objekter (en egendefinert rapporttype tillater høyst fire objektrelasjoner), skjermen blir til relaterte lister inni relaterte lister, og koden blir mer komplisert.

En verdiliste starter ofte livet som en plukkliste og gjør seg over tid fortjent til et eget objekt. La den gjøre seg fortjent til det.

Click to enlarge

Noen ganger endrer skala svaret

Et design som fungerer utmerket med noen tusen poster, kan oppføre seg helt annerledes med millioner.

Så ikke se på diagrammet alene. Kjenn tallene.

Steve Trucking gjør rundt en million leveringer i året, med en vekst på 30 % i året. Hver levering samler rundt åtte statusoppdateringer. Det er åtte millioner statusposter i år, og rundt 13,5 millioner i året innen år tre. Legg til fire eller fem millioner bilder i året.

Samme modell. Helt annen arkitektur.

Vi går mye dypere i Arkitektur i stor skala. Foreløpig: husk at volum kan endre en beslutning i datamodelleringen. En relasjon som er logisk riktig, er ikke automatisk det beste fysiske designet i enhver skala.

Ulike brukere vil ha ulike former

Så langt har vi tenkt på det operative systemet. Koordinatorer legger ruter for leveringer. Team lukker stopp. Systemet endrer seg mens virksomheten går.

Men virksomheten vil også analysere mange års historikk. Hvilke partnere og regioner blir forsinket? Hvordan har leveringstiden endret seg? Hvor ofte trenger installasjoner et nytt besøk?

Et analytisk system kan ønske den samme informasjonen organisert annerledes. Du kommer til å høre begreper som datavarehus, fakta, dimensjon og stjerneskjema. Vi pakker dem ikke ut her; hos Steve Trucking er det Snowflake-varehuset, og vi kommer tilbake til det senere i kurset.

Foreløpig: ulike brukere kan trenge ulike former av den samme sannheten.

KI legger til enda en bruker

Og nå finnes det enda en bruker av dataene: KI (AI).

En mottaker sender en SMS: «Hvor er leveringen min?» En KI-assistent kunne slått opp dette:

Levering 10427, rute 3312, stopp 7, lastebil 117, tidsvindu 13.00–15.00.

En tradisjonell applikasjon er helt fornøyd med å følge de relasjonene. Men for å svare mottakeren trenger assistenten kontekst satt sammen fra flere steder:

Oppvaskmaskinen din fra Redrock er det sjuende stoppet på dagens rute fra distribusjonssenteret i Phoenix. Lastebilen er tre stopp unna, og du er fortsatt innenfor tidsvinduet ditt kl. 13–15.

Vi har tatt informasjon fra flere relaterte entiteter og satt sammen en flatere, kontekstrik representasjon for én bestemt bruker.

Det betyr ikke at jeg ødelegger den normaliserte modellen min. Og det betyr absolutt ikke «KI liker flate data, så legg alt i ett gigantisk objekt». Ikke gjør det.

Sannhetskilden forblir ren. KI får en representasjon bygget for jobben den gjør. Det er den samme ideen vi nettopp så med analyse:

Én sannhetskilde kan støtte flere former for bruk.

Vi går mye dypere inn i grounding og henting senere i kurset.

Ikke lag flere sannheter

Det finnes en fare her.

Hvis jeg kopierer regionen over på leveringen for rapporteringens skyld, sender en flatere versjon til Snowflake og bygger en kontekstrik versjon for KI-assistenten, hvilken er da riktig?

Det spørsmålet trenger et svar. Jeg vil vite hvor den autoritative verdien bor. Alt annet er en representasjon av den sannheten for et formål.

Det stedet er system of record (kildesystemet). Denormaliserte kopier kan være bra: stoppskjermen, resultatkortet, Snowflake og KI-konteksten gjør hver sin jobb bedre med en form som er bygget for dem, og det er helt greit å slå opp i dem. Men når noe endres, starter endringen i kildesystemet, typisk relasjonsmodellen, og flyter utover til hver kopi. Ingen retter regionen i Snowflake eller redigerer KI-ens kontekst for hånd. Rett det ved kilden, og la endringen flyte.

Click to enlarge

Og det betyr mest når data endres. Hvis et distribusjonssenter flytter til en annen region i dag, skal forrige måneds leveringer vise den nye regionen? Kanskje. Kanskje ikke. For historikken trenger jeg kanskje regionen som var sann da leveringen skjedde. Det er ikke lenger et synkroniseringsproblem. Det er en forretningsbeslutning.

Derfor bør denormalisering aldri skje ved et uhell. Hvert duplisert faktum reiser spørsmål om eierskap, synkronisering, historikk og tillit. Det er avveiningstenkningen fra kapittel 1: vit hva du kjøper (en enklere skjerm, en enklere rapport, bedre kontekst for KI) og hva du betaler (dupliserte data, synkronisering, mer komplisert eierskap til sannheten). Og fordi vi startet fra en ren logisk modell, kan vi peke på hver kopi og si: «Jeg vet at dette hører hjemme der borte. Jeg legger en representasjon av det her på grunn av dette kravet.» Det er en beslutning vi kan gjennomgå, utfordre og skrive ned, slik at neste arkitekt vet hvorfor.

Hva en arkitekt bestemmer her

Når jeg vurderer denormalisering, bestemmer jeg:

• Hvor den autoritative kilden til hvert forretningsfaktum bor.
• Om den rene modellen skaper reelle problemer for brukere, rapportering, skala eller ytelse.
• Om en enklere representasjon er verdt dupliseringen, og hvordan kopien forblir pålitelig.
• Om historiske verdier skal endres når den gjeldende kilden endres.
• Om analyse eller KI trenger en annen form på dataene enn det operative systemet.

Utgangspunktet endrer seg aldri: vit hvor sannheten hører hjemme. Når kravene rettferdiggjør det, former du den for levering.

Nå kommer Salesforce tilbake i bildet. Vi skal gjøre det vi har designet, om til en fysisk datamodell.

Les mer

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24. juni 2019 (på engelsk, kontrollert 2026-10-12): en egendefinert rapporttype «can span up to 4 object relationships» (kan spenne over opptil fire objektrelasjoner).
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2. januar 2026 (på engelsk, kontrollert 2026-10-12): AKC anerkjenner 205 raser, inkludert de tre nykommerne.
• Til moro: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (på engelsk, kontrollert 2026-10-12): den internasjonale føderasjonens raseliste, i ti grupper. Bla gjennom den, så skjønner du hvorfor Rase gjorde seg fortjent til en egen tabell.