Bygg den logiska modellen

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

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 3 av 6 i kapitlet Modellera data för mening, kapitel 2 i kursen Data Architect. Varje modul står på egna ben. Föregående: Rita relationerna · Nästa: Lägg data där de hör hemma

Frågan den här modulen besvarar: Hur gör jag en konceptuell modell till en logisk datamodell?

Den konceptuella modellen berättade vad som finns hos Steve Trucking och hur det hänger ihop: detaljhandelspartner och deras distributionscentraler, manifest och leveranser, mottagare, rutter och stopp, team, lastbilar och teamtilldelningar. Det räcker för ett mycket produktivt samtal med verksamheten. Men till slut behöver jag fler detaljer. Vad behöver vi veta om en leverans? Vad skiljer en distributionscentral från en annan? Hur identifierar vi en mottagare? Vad hör till en teamtilldelning snarare än till teamet eller lastbilen? De frågorna flyttar oss från en konceptuell modell mot en logisk datamodell, och vi bygger fortfarande inte i Salesforce än.

Sitt, stanna, modellera

Först tillbaka till hundarna. Vi har rutorna och linjerna. Nu två nya frågor: vad vet vi om varje sak, och hur skiljer vi den ena från den andra?

Vad beskriver den? En hund har ett namn och ett födelsedatum. En ägare har ett namn, ett telefonnummer och en adress. Ett trick har ett namn och en svårighetsgrad. Varje fakta hamnar på den ruta den beskriver.

Sedan kopplingen. Hur bra Bella gör Sitt, och när hon lärde sig det: beskriver det Bella? Inte riktigt; hon är bättre på vissa trick än andra. Beskriver det Sitt? Nej; varje hund gör Sitt på sitt sätt. Det beskriver Bella och Sitt tillsammans, så det hör hemma på Hundtrick: färdighetsnivån och datumet då tricket lärdes in. Det är därför kopplingen finns: vissa fakta hör bara till paret.

Vilken hund är vilken? Pröva namnet först. Det finns väldigt många hundar som heter Max, så namnet är inte unikt. Ägarens telefonnummer? Marcus har två hundar på samma telefon, folk byter nummer, och det är någons personuppgifter, som skulle kopieras in i varje system som någonsin pekar på en hund. Chipnumret ser bättre ut: det är unikt, och det ändras inte. Men en ny valp kanske inte är chipmärkt än, och en nyckel kan inte vara tom. Så chipnumret blir kvar, som något hunden också är känd under, och hunden får ett eget hund-ID: ett nummer som gör ett tråkigt jobb, att skilja en hund från en annan.

Click to enlarge

Det är samma frågor som vi nu ska ställa till Steve Trucking, och skälen till att namnet, telefonen och chipnumret var och ett inte räcker blir en regel jag har hållit fast vid i många år.

Konceptuellt säger vad som finns; logiskt säger vad det betyder som data

Ta lastbil (Truck). Vad behöver jag veta om en lastbil? Kanske dess enhetsnummer, VIN, märke, modell, årsmodell, registreringsnummer, aktuella körsträcka och status. Det är attribut till lastbilen.

Ta nu leverans (Delivery). Kanske detaljhandelspartnerns ordernummer, leveransdatum, det utlovade tidsfönstret, den faktiska ankomsttiden, status, och om den innehåller en installation eller en bortforsling. Återigen attribut.

Den konceptuella modellen berättade att leveransen finns. Den logiska modellen börjar berätta vad en leverans betyder som data. En enkel ruta som Lastbil eller Leverans kan stå för en hel uppsättning fält.

Click to enlarge

Trots det förblir rutorna enkla i de flesta av våra diagram, av tre skäl. Antalet fält växer. Fält blir snabbt inaktuella. Och varje fält har detaljer som är svåra att visa i en objektmodell: API-namn, etikett, datatyp och längd. De detaljerna kommer definitivt att dokumenteras, bara inte i den första datamodellen. När det verkligen hjälper berättelsen att visa några nyckelfält ritar jag en detaljerad datamodell: ett fokuserat utsnitt, med bara de fält som spelar roll för poängen.

Attribut ska beskriva entiteten

Här är en enkel fråga jag använder när jag tittar på ett attribut: vad beskriver det här? Lastbilens märke beskriver tydligt lastbilen. Men teammedlemmarnas namn på en leverans? Beskriver de leveransen? Eller beskriver de ett team, som hade en teamtilldelning, som täckte rutten, som innehöll det här stoppet?

Det är här en datamodell börjar avslöja saker som ser helt rimliga ut på en skärm. En koordinator säger: ”Jag vill se teamets namn på leveransen.” Det är ett giltigt krav på användarupplevelsen. Det är inte nödvändigtvis ett krav på att lagra teamets namn på leveransen. Det är två olika saker, och vi återkommer till det med normalisering. Tills vidare: skaffa dig vanan att fråga vilken sak det här faktumet faktiskt beskriver. Den frågan kommer att bespara dig mycket besvär.

Sedan måste vi prata om unika ID:n

Attribut beskriver saker. Men det finns ett annat problem att lösa: hur vet jag vilken sak som är vilken?

Två mottagare heter John Smith. Är de samma person? Kanske; kanske inte. Ett namn räcker inte. En adress? Folk flyttar. Telefonnummer ändras. E-postadresser ändras. Till och med en detaljhandelspartners namn kan ändras.

Det leder oss till nycklar: det som låter oss identifiera något unikt i vår modell. Det är ett område där jag har utvecklat en ganska stark åsikt genom åren. Av ett ID vill jag ha fyra saker:

Unikt. Oföränderligt. Betydelselöst. Aldrig personuppgifter.

Unikt. Ett ID måste identifiera exakt en sak. Om två leveranser kan ha samma värde är det inget pålitligt leverans-ID. Namn är oftast inte unika, adresser är inte nödvändigtvis unika, och telefonnummer delas. Till och med värden som ser unika ut i dag kanske inte är det när du väl har tillräckligt med data. Så fråga: kan två av de här någonsin ha samma värde? Om svaret är ja, var mycket försiktig med att använda det som postens unika ID.

Oföränderligt. Det här missas ofta. Om vi identifierar en detaljhandelspartner med dess namn och partnern byter namn, fick vi då en ny partner? Nej. Affärsentiteten förblev densamma; ett av dess attribut ändrades. En posts unika ID ska överleva förändringar i det den identifierar, och det utesluter namn, e-postadresser, telefonnummer, adresser och användarnamn, hur bekväma de än ser ut när vi först bygger ett system.

Betydelselöst. Det här låter konstigt första gången du hör det. Varför skulle jag vilja att ett ID saknar betydelse? För att betydelse förändras. Tänk dig att någon bygger ett leverans-ID som kodar in DC:n, detaljhandelspartnern, leveransdatumet och ett löpnummer: PHX-KEY-20261002-0042. Det ser smart ut. Sedan bokar mottagaren om till fredag. Ändrar vi ID:t? Om vi inte gör det ljuger det för oss. Om vi gör det har vi ändrat leveransens unika ID för att ett av dess attribut ändrades, och varje system som lagrat det gamla ID:t har just tappat bort leveransen. ID:t försökte göra två jobb: identifiera leveransen och beskriva den. Jag låter hellre attributen beskriva den och låter ID:t göra ett tråkigt jobb: identifiera den. Tråkiga ID:n är bra ID:n.

Aldrig personuppgifter. Den här är så viktig att jag håller den separat. Använd inte personuppgifter (PII) som ID bara för att de ser unika ut. Hos Steve Trucking är det frestande att känna igen en mottagare på telefonnumret. Men en nyckel kopieras överallt där system behöver koppla ihop poster: integrationer, exporter, loggar, statusfiler tillbaka till detaljhandelspartnerna, datalagret, testdata. Gör ett telefonnummer till nyckel, så har du spritt en mottagares personuppgifter genom hela arkitekturen.

En nyckel måste också finnas för varje post: aldrig null eller tom. Om vissa personer inte vill, eller inte ska behöva, ge dig ett värde kan det värdet inte vara nyckeln. Det är därför system skapar egna interna ID:n, och personuppgifter, om du alls behöver dem, blir ett skyddat attribut.

Så min regel är: unikt, oföränderligt, betydelselöst, aldrig personuppgifter.

Naturliga nycklar och surrogatnycklar

Databasfolk har namn på en del av det här. En naturlig nyckel finns redan i affärsdata: en lastbils VIN är ett bra exempel. Vår applikation hittade inte på den, och den har redan en betydelse. En surrogatnyckel skapas enbart för att identifiera posten; den beskriver ingenting, den bara identifierar.

I de flesta arkitekturer föredrar jag en surrogatnyckel som internt post-ID och behåller de viktiga naturliga identifierarna som attribut. Det gör inte naturliga identifierare dåliga; de är ofta extremt viktiga. Jag gör dem bara inte automatiskt till postens unika ID. Fråga vad som händer om värdet rättas, formateras om, ersätts, återanvänds, saknas eller kommer från mer än ett källsystem. Det är där ett enkelt beslut blir ett arkitekturbeslut.

En sak kan ha flera användbara ID:n

Det interna post-ID:t är inte nödvändigtvis det ID som alla andra system använder. Steve Trucking kanske identifierar en leverans internt med ett genererat ID. Varje detaljhandelspartner känner samma leverans under sitt eget ordernummer: Keystone i sitt CSV-manifest, Redrock i sitt API, Brightwave i sina EDI-meddelanden. Och de åtta årens historik i RouteDesk, det gamla dispatchverktyget, använder RouteDesks egna leverans-ID:n.

De ID:na spelar roll. Vi måste behålla dem och mappa dem rätt, för en statusuppdatering måste gå tillbaka till varje partner under dess nummer. Men alla behöver inte bli leveransens unika ID. ”Vad är dess ID?” kan ha mer än ett svar, och arkitekten måste veta vilket ID som är auktoritativt i vilket sammanhang. Vi återkommer till det med masterdata och integration.

Relationer är beroende av unika ID:n

Gå nu tillbaka till linjerna vi ritade. Ett manifest listar leveranser. En mottagare tar emot leveranser. Ett team har teamtilldelningar. De relationerna fungerar bara för att vi pålitligt kan identifiera sakerna i båda ändar.

Här är där det biter hos Steve Trucking. En detaljhandelspartner reviderar sitt manifest samma dag: en order avbokad, en vara utbytt, en ny adress. Om vi inte kan matcha den reviderade raden mot den leverans vi redan har, via partnerns ordernummer, skapar vi en andra leverans för samma kylskåp, och ett team kan dyka upp två gånger. Rutor, attribut, nycklar och relationer är inte separata idéer. De är alla delar av samma modell.

Click to enlarge

Nu kanske du tänker: ”Salesforce ger varje post ett ID.” Helt rätt, och dit kommer vi. Om data bor i Salesforce får varje post ett ID som Salesforce genererar. Det är kryptiskt och svårläst, så vi brukar också visa ett ID-fält som människor kan använda, som ett leveransnummer D-000184227, ett Auto Number-fält. Folk tror ofta att det numret är postens ID, men det är det inte: Salesforce-ID:t finns fortfarande där under. Ett externt system eller en databas, Oracle eller SQL Server, har också sina egna unika ID:n. Men arkitekturen kan till slut omfatta Salesforce, ekonomins ERP, Snowflake, Data 360, partnernas system och system som inte finns än. Den logiska modellen beskriver affärsdata utan att göra varje beslut beroende av en enda teknik. Hur Salesforce fysiskt implementerar den är ett senare steg.

Vad en arkitekt bestämmer här

När jag gör en konceptuell modell till en logisk modell bestämmer jag:

• Vilka attribut som faktiskt beskriver varje entitet.
• Hur varje entitet identifieras unikt, och om det ID:t är stabilt nog att vara dess unika ID.
• Vilka affärs-ID:n (partnernas ordernummer, gamla ID:n) som måste behållas och mappas.
• Om känslig information används som nyckel.
• Om relationerna kopplar ihop entiteter via pålitliga unika ID:n.

Nu har vi entiteter, relationer, attribut och unika ID:n: början på en riktig logisk datamodell. Men det finns fortfarande ett problem. Det är väldigt lätt att lägga helt giltiga data på fel ställe. Det är där normalisering kommer in.

Utforska vidare

• Custom Field Types (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09): Auto Number ger varje post ett unikt nummer med ett visningsformat, till exempel ett prefix och inledande nollor; det är inte postens Salesforce-ID. Se även Auto-Number Fields Are Not Always Sequential (opens in a new tab) (på engelska, kontrollerad 2026-10-09).