Bygg den logiske modellen

🌐 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 3 av 6 i kapitlet Modeller data for mening, kapittel 2 i kurset Data Architect. Hver modul står på egne ben. Forrige: Tegn relasjonene · Neste: Plasser data der de hører hjemme

Spørsmålet denne modulen besvarer: Hvordan gjør jeg en konseptuell modell om til en logisk datamodell?

Den konseptuelle modellen fortalte oss hva som finnes hos Steve Trucking og hvordan det henger sammen: detaljhandelspartnere (Retail Partners) og distribusjonssentrene deres, manifester og leveringer, mottakere (Recipients), ruter og stopp, team, lastebiler og teamtildelinger. Det er nok til en svært produktiv samtale med virksomheten. Men før eller siden trenger jeg flere detaljer. Hva trenger vi å vite om en levering? Hva gjør ett distribusjonssenter forskjellig fra et annet? Hvordan identifiserer vi en mottaker? Hva hører til en teamtildeling og ikke til teamet eller lastebilen? De spørsmålene flytter oss fra en konseptuell modell mot en logisk datamodell, og vi bygger fortsatt ikke Salesforce.

Sitt, bli, modellér

Først tilbake til hundene. Vi har boksene og linjene. Nå kommer to nye spørsmål: hva vet vi om hver ting, og hvordan skiller vi den ene fra den andre?

Hva beskriver den? En hund har et navn og en fødselsdato. En eier har et navn, et telefonnummer og en adresse. Et triks har et navn og en vanskelighetsgrad. Hvert faktum hører hjemme på boksen det beskriver.

Så koblingsobjektet. Hvor godt Bella gjør Sitt, og når hun lærte det: beskriver det Bella? Ikke helt; hun er bedre til noen triks enn andre. Beskriver det Sitt? Nei; hver hund gjør Sitt på sin måte. Det beskriver Bella og Sitt sammen, så det hører hjemme på Hundetriks: ferdighetsnivået og datoen hun lærte det. Det er derfor koblingsobjektet finnes: noen fakta hører bare til paret.

Hvilken hund er hvilken? Prøv navnet først. Det finnes mange hunder som heter Max, så navnet er ikke unikt. Eierens telefonnummer? Marcus har to hunder på samme telefon, folk bytter nummer, og det er noens personopplysninger, som ville blitt kopiert inn i hvert eneste system som noen gang peker på en hund. Mikrochipnummeret ser bedre ut: det er unikt, og det endrer seg ikke. Men en ny valp er kanskje ikke chippet ennå, og en nøkkel kan ikke være tom. Så mikrochipen blir værende, som noe hunden også er kjent som, og hunden får sin egen Hund-ID: et nummer som gjør én kjedelig jobb, nemlig å skille én hund fra en annen.

Click to enlarge

Det er de samme spørsmålene vi nå skal stille til Steve Trucking, og grunnene til at navnet, telefonen og mikrochipen hver for seg kommer til kort, blir til en regel jeg har holdt fast ved i mange år.

Konseptuell forteller meg hva som finnes; logisk forteller meg hva det betyr som data

Ta lastebil. Hva trenger jeg å vite om en lastebil? Kanskje enhetsnummer, VIN (understellsnummer), merke, modell, årsmodell, registreringsnummer, nåværende kilometerstand og status. Det er attributter til lastebilen.

Ta så levering. Kanskje detaljhandelspartnerens ordrenummer, leveringsdatoen, det lovede tidsvinduet, faktisk ankomsttid, status, og om den omfatter installasjon eller bortkjøring. Igjen: attributter.

Den konseptuelle modellen fortalte oss at levering finnes. Den logiske modellen begynner å fortelle oss hva en levering betyr som data. En enkel boks som lastebil eller levering kan stå for et helt sett med felt.

Click to enlarge

Likevel holder boksene seg enkle i de fleste diagrammene våre, av tre grunner. Antallet felt vokser. Felt blir fort utdaterte. Og hvert felt har detaljer som er vanskelige å vise i en objektmodell: API-navn, etikett, datatype og lengde. De detaljene blir absolutt dokumentert, bare ikke i den første datamodellen. Når det virkelig hjelper historien å vise noen få nøkkelfelt, tegner jeg en detaljert datamodell: et fokusert utsnitt, med bare feltene som betyr noe for poenget.

Attributter skal beskrive entiteten

Her er et enkelt spørsmål jeg bruker når jeg ser på et attributt: hva beskriver dette? Lastebilens merke beskriver tydelig lastebilen. Men hva med navnene på teammedlemmene på en levering? Beskriver de leveringen? Eller beskriver de et team, som hadde en teamtildeling, som dekket ruten, som inkluderte dette stoppet?

Det er her en datamodell begynner å avsløre ting som ser helt fornuftige ut på en skjerm. En koordinator sier: «Jeg vil se navnene på teamet på leveringen.» Det er et gyldig krav til brukeropplevelsen. Det er ikke nødvendigvis et krav om å lagre navnene på teamet på leveringen. Det er to forskjellige ting, og vi kommer tilbake til det med normalisering. Foreløpig: venn deg til å spørre hvilken ting dette faktumet egentlig beskriver. Det spørsmålet sparer deg for mye trøbbel.

Så må vi snakke om unike ID-er

Attributter beskriver ting. Men det er et annet problem som må løses: hvordan vet jeg hvilken ting som er hvilken?

To mottakere heter John Smith. Er de samme person? Kanskje, kanskje ikke. Et navn er ikke nok. En adresse? Folk flytter. Telefonnumre endres. E-postadresser endres. Selv navnet på en detaljhandelspartner kan endres.

Det bringer oss til nøkler: det som lar oss identifisere noe entydig i modellen. Det er et område der jeg har fått en ganske sterk mening gjennom årene. Til en ID vil jeg ha fire ting:

Unik. Uforanderlig. Uten mening. Aldri PII.

Unik. En ID må identifisere nøyaktig én ting. Hvis to leveringer kan ha samme verdi, er det ikke en pålitelig leverings-ID. Navn er vanligvis ikke unike, adresser er ikke nødvendigvis unike, og telefonnumre deles. Selv verdier som ser unike ut i dag, er det kanskje ikke når du har nok data. Så spør: kan to av disse noen gang ha samme verdi? Hvis svaret er ja, vær veldig forsiktig med å bruke den som postens unike ID.

Uforanderlig. Denne blir ofte oversett. Hvis vi identifiserer en detaljhandelspartner ved navnet og partneren bytter navn, har vi da fått en ny partner? Nei. Forretningsentiteten er den samme; ett av attributtene endret seg. En posts unike ID skal overleve endringer i tingen den identifiserer, og det utelukker navn, e-postadresser, telefonnumre, adresser og brukernavn, uansett hvor praktiske de ser ut når vi først bygger et system.

Uten mening. Dette høres rart ut første gang du hører det. Hvorfor skulle jeg ville at en ID skal være uten mening? Fordi mening endrer seg. Tenk deg at noen bygger en leverings-ID som koder inn DC-et, detaljhandelspartneren, leveringsdatoen og et løpenummer: PHX-KEY-20261002-0042. Det ser smart ut. Så flytter mottakeren leveringen til fredag. Endrer vi ID-en? Hvis vi ikke gjør det, lyver den for oss. Hvis vi gjør det, har vi endret leveringens unike ID fordi ett av attributtene endret seg, og hvert system som lagret den gamle ID-en, har nettopp mistet sporet av den. ID-en prøvde å gjøre to jobber: identifisere leveringen og beskrive den. Jeg vil heller la attributtene beskrive den og la ID-en gjøre én kjedelig jobb: identifisere den. Kjedelige ID-er er gode ID-er.

Aldri PII. Denne er viktig nok til at jeg holder den for seg selv. Ikke bruk personidentifiserbar informasjon (PII) som ID bare fordi den ser unik ut. Hos Steve Trucking er det fristende å kjenne igjen en mottaker på telefonnummeret. Men en nøkkel blir kopiert overalt der systemer trenger å koble poster: integrasjoner, eksporter, logger, statusfiler tilbake til detaljhandelspartnerne, datavarehuset, testdata. Gjør et telefonnummer til nøkkelen, så har du spredt mottakerens personopplysninger gjennom hele arkitekturen.

En nøkkel må også være til stede for hver eneste post: aldri null eller tom. Hvis noen ikke vil, eller ikke burde måtte, gi deg en verdi, kan den verdien ikke være nøkkelen. Det er derfor systemer utsteder sine egne interne ID-er, og personopplysninger, hvis du i det hele tatt trenger dem, blir et beskyttet attributt.

Så regelen min er: unik, uforanderlig, uten mening, aldri PII.

Naturlige nøkler og surrogatnøkler

Databasefolk har navn på noe av dette. En naturlig nøkkel finnes allerede i forretningsdataene: en lastebils VIN er et godt eksempel. Applikasjonen vår fant den ikke på, og den har allerede en betydning. En surrogatnøkkel lages spesielt for å identifisere posten; den beskriver ingenting, den bare identifiserer.

I de fleste arkitekturer foretrekker jeg en surrogatnøkkel som intern post-ID og beholder de viktige naturlige ID-ene som attributter. Det gjør ikke naturlige ID-er dårlige; de er ofte ekstremt viktige. Jeg gjør dem bare ikke automatisk til postens unike ID. Spør hva som skjer hvis verdien blir rettet, formatert om, erstattet, gjenbrukt, mangler, eller kommer fra mer enn ett kildesystem. Det er der en beslutning som ser enkel ut, blir en arkitekturbeslutning.

Én ting kan ha flere nyttige ID-er

Den interne post-ID-en er ikke nødvendigvis ID-en alle andre systemer bruker. Steve Trucking kan identifisere en levering internt med en generert ID. Hver detaljhandelspartner kjenner den samme leveringen ved sitt eget ordrenummer: Keystone i CSV-manifestet sitt, Redrock i API-et sitt, Brightwave i EDI-meldingene sine. Og de åtte årene med historikk i RouteDesk, det gamle verktøyet for utkjøring, bruker RouteDesks egne leverings-ID-er.

De ID-ene betyr noe. Vi må ta vare på dem og koble dem riktig, fordi en statusoppdatering må gå tilbake til hver partner under dens nummer. Men de trenger ikke alle å bli leveringens unike ID. «Hva er ID-en?» kan ha mer enn ett svar, og arkitekten må vite hvilken ID som er autoritativ i hvilken sammenheng. Vi kommer tilbake til dette med masterdata og integrasjon.

Relasjoner er avhengige av unike ID-er

Gå nå tilbake til linjene vi tegnet. Et manifest lister opp leveringer. En mottaker mottar leveringer. Et team har teamtildelinger. De relasjonene fungerer bare fordi vi pålitelig kan identifisere tingene i begge ender.

Her er det det svir hos Steve Trucking. En detaljhandelspartner reviderer manifestet sitt samme dag: en ordre kansellert, en vare byttet, en ny adresse. Hvis vi ikke kan matche den reviderte linjen mot leveringen vi allerede har, via partnerens ordrenummer, oppretter vi en ny levering for det samme kjøleskapet, og et team kan dukke opp to ganger. Bokser, attributter, nøkler og relasjoner er ikke separate ideer. De er alle deler av den samme modellen.

Click to enlarge

Nå tenker du kanskje: «Salesforce gir hver post en ID.» Riktig, og vi kommer dit. Hvis dataene bor i Salesforce, får hver post en ID generert av Salesforce. Den er kryptisk og vanskelig å lese, så vi viser vanligvis også et ID-felt folk kan bruke, som et leveringsnummer D-000184227, et Auto Number-felt. Folk tror ofte at det nummeret er postens ID, men det er det ikke: Salesforce-ID-en ligger der fortsatt under. Et eksternt system eller en database, Oracle eller SQL Server, har også sine egne unike ID-er. Men arkitekturen kan etter hvert omfatte Salesforce, ERP-systemet for økonomi, Snowflake, Data 360, partnernes systemer og systemer som ikke finnes ennå. Den logiske modellen beskriver forretningsdataene uten å gjøre hver beslutning avhengig av én teknologi. Hvordan Salesforce implementerer det fysisk, er et senere steg.

Hva en arkitekt bestemmer her

Når jeg gjør en konseptuell modell om til en logisk modell, bestemmer jeg:

• Hvilke attributter som faktisk beskriver hver entitet.
• Hvordan hver entitet identifiseres entydig, og om den ID-en er stabil nok til å være dens unike ID.
• Hvilke forretnings-ID-er (partnernes ordrenumre, gamle ID-er) som må tas vare på og kobles.
• Om sensitiv informasjon brukes som nøkkel.
• Om relasjonene kobler entiteter gjennom pålitelige unike ID-er.

Nå har vi entiteter, relasjoner, attributter og unike ID-er: begynnelsen på en ekte logisk datamodell. Men det er fortsatt et problem. Det er veldig lett å legge helt gyldige data på feil sted. Det er der normalisering kommer inn.

Les mer

• Custom Field Types (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09): Auto Number gir hver post et unikt nummer med et visningsformat, for eksempel et prefiks og innledende nuller; det er ikke postens Salesforce-ID. Se også Auto-Number Fields Are Not Always Sequential (opens in a new tab) (på engelsk, kontrollert 2026-10-09).