Byg den logiske model
Findes også på 28 sprog
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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 3 af 6 i kapitlet Modellér data for betydning, kapitel 2 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Tegn relationerne · Næste: Placér data, hvor de hører hjemme
Spørgsmålet, dette modul besvarer: Hvordan gør jeg en konceptuel model til en logisk datamodel?
Den konceptuelle model fortalte os, hvad der findes hos Steve Trucking, og hvordan det hænger sammen: detailpartnere og deres distributionscentre, manifester og leveringer, modtagere, ruter og stop, teams, lastbiler og teamtildelinger. Det er nok til en meget produktiv samtale med forretningen. Men på et tidspunkt har jeg brug for flere detaljer. Hvad skal vi vide om en levering? Hvad gør ét distributionscenter forskelligt fra et andet? Hvordan identificerer vi en modtager? Hvad hører til en teamtildeling og ikke til teamet eller lastbilen? Det er de spørgsmål, der flytter os fra en konceptuel model mod en logisk datamodel, og vi bygger stadig ikke i Salesforce endnu.
Sit, bliv, modellér
Sektion kaldt “Sit, bliv, modellér ”Først tilbage til hundene. Vi har kasserne og stregerne. Nu kommer to nye spørgsmål: hvad ved vi om hver ting, og hvordan kender vi dem fra hinanden?
Hvad beskriver den? En hund har et navn og en fødselsdato. En ejer har et navn, et telefonnummer og en adresse. Et trick har et navn og en sværhedsgrad. Hver kendsgerning kommer på den kasse, den beskriver.
Så forbindelsen. Hvor godt Bella gør Sit, og hvornår hun lærte det: beskriver det Bella? Ikke helt; hun er bedre til nogle tricks end andre. Beskriver det Sit? Nej; hver hund gør Sit forskelligt. Det beskriver Bella og Sit sammen, så det hører hjemme på Hundetrick: færdighedsniveauet og datoen, hun lærte det. Det er derfor, forbindelsesobjektet findes: nogle kendsgerninger hører kun til parret.
Hvilken hund er hvilken? Prøv navnet først. Der er mange hunde, der hedder Max, så navnet er ikke unikt. Ejerens telefonnummer? Marcus har to hunde på det samme nummer, folk skifter nummer, og det er en persons personoplysninger, som ville blive kopieret ind i hvert system, der nogensinde peger på en hund. Mikrochipnummeret ser bedre ud: det er unikt, og det ændrer sig ikke. Men en ny hvalp er måske ikke chippet endnu, og en nøgle kan ikke være tom. Så mikrochippen bliver, som noget hunden også er kendt under, og hunden får sit eget hunde-id: et nummer, der udfører ét kedeligt job, nemlig at kende den ene hund fra den anden.
Det er de samme spørgsmål, vi nu stiller til Steve Trucking, og grundene til, at navnet, telefonen og mikrochippen hver især ikke slår til, bliver til en regel, jeg har holdt fast i i årevis.
Den konceptuelle model fortæller mig, hvad der findes; den logiske fortæller mig, hvad det betyder som data
Sektion kaldt “Den konceptuelle model fortæller mig, hvad der findes; den logiske fortæller mig, hvad det betyder som data ”Tag lastbil. Hvad skal jeg vide om en lastbil? Måske dens enhedsnummer, stelnummer (VIN), mærke, model, årgang, nummerplade, aktuelle kilometertal og status. Det er attributter for lastbilen.
Tag så levering. Måske detailpartnerens ordrenummer, leveringsdatoen, det lovede tidsvindue, det faktiske ankomsttidspunkt, status, og om den omfatter installation eller bortkørsel. Igen attributter.
Den konceptuelle model fortalte os, at levering findes. Den logiske model begynder at fortælle os, hvad en levering betyder som data. En enkel kasse som Lastbil eller Levering kan stå for et helt sæt felter.
Alligevel forbliver kasserne enkle i de fleste af vores diagrammer, af tre grunde. Antallet af felter vokser. Felter bliver hurtigt forældede. Og hvert felt har detaljer, der er svære at vise i en objektmodel: API-navn, etiket, datatype og længde. De detaljer bliver helt sikkert registreret, bare ikke i den første datamodel. Når det virkelig hjælper historien at vise nogle få nøglefelter, tegner jeg en detaljeret datamodel: et fokuseret udsnit med kun de felter, der betyder noget for pointen.
Attributter skal beskrive entiteten
Sektion kaldt “Attributter skal beskrive entiteten ”Her er et enkelt spørgsmål, jeg bruger, når jeg kigger på en attribut: hvad beskriver den? Lastbilens mærke beskriver tydeligvis lastbilen. Men hvad med teammedlemmernes navne på en levering? Beskriver de leveringen? Eller beskriver de et team, som havde en teamtildeling, som dækkede ruten, som omfattede dette stop?
Det er her, en datamodel begynder at afsløre ting, der ser helt fornuftige ud på en skærm. En koordinator siger: »Jeg vil gerne se teamets navne på leveringen.« Det er et gyldigt krav til brugeroplevelsen. Det er ikke nødvendigvis et krav om at gemme teamets navne på leveringen. Det er to forskellige ting, og vi vender tilbage til det med normalisering. Indtil videre: vænn dig til at spørge, hvilken ting den her kendsgerning faktisk beskriver. Det spørgsmål sparer dig for mange problemer.
Så må vi tale om unikke id’er
Sektion kaldt “Så må vi tale om unikke id’er ”Attributter beskriver ting. Men der er et andet problem, vi skal løse: hvordan ved jeg, hvilken ting der er hvilken?
To modtagere hedder John Smith. Er de den samme person? Måske, måske ikke. Et navn er ikke nok. En adresse? Folk flytter. Telefonnumre ændrer sig. E-mailadresser ændrer sig. Selv en detailpartners navn kan ændre sig.
Det bringer os til nøgler: det, der gør det muligt at identificere noget entydigt i vores model. Det er et område, hvor jeg har udviklet en ret stærk holdning gennem årene. Til et id vil jeg have fire ting:
Unikt. Uforanderligt. Uden betydning. Aldrig personoplysninger.
Unikt. Et id skal identificere præcis én ting. Hvis to leveringer kan have den samme værdi, er det ikke et pålideligt id for en levering. Navne er som regel ikke unikke, adresser er ikke nødvendigvis unikke, og telefonnumre bliver delt. Selv værdier, der ser unikke ud i dag, er det måske ikke, når du har data nok. Så spørg: kan to af dem nogensinde have den samme værdi? Hvis svaret er ja, så vær meget forsigtig med at bruge den som postens unikke id.
Uforanderligt. Det her bliver overset. Hvis vi identificerer en detailpartner ved dens navn, og partneren skifter navn, har vi så fået en ny partner? Nej. Forretningsentiteten forblev den samme; en af dens attributter ændrede sig. En posts unikke id skal overleve ændringer i den ting, det identificerer, og det udelukker navne, e-mailadresser, telefonnumre, adresser og brugernavne, uanset hvor praktiske de ser ud, når vi lige er begyndt at bygge et system.
Uden betydning. Det lyder mærkeligt, første gang du hører det. Hvorfor skulle jeg ønske, at et id er uden betydning? Fordi betydning ændrer sig. Forestil dig, at nogen bygger et leverings-id, der koder DC’et, detailpartneren, leveringsdatoen og et løbenummer: PHX-KEY-20261002-0042. Det ser smart ud. Så flytter modtageren leveringen til fredag. Ændrer vi id’et? Hvis vi ikke gør, lyver det for os. Hvis vi gør, har vi ændret leveringens unikke id, fordi en af dens attributter ændrede sig, og hvert system, der gemte det gamle id, har lige mistet sporet af den. Id’et prøvede at udføre to job: at identificere leveringen og at beskrive den. Jeg vil hellere lade attributterne beskrive den og lade id’et udføre ét kedeligt job: at identificere den. Kedelige id’er er gode id’er.
Aldrig personoplysninger. Den her er vigtig nok til, at jeg holder den for sig. Brug ikke personhenførbare oplysninger som id, bare fordi de ser unikke ud. Hos Steve Trucking er det fristende at genkende en modtager på telefonnummeret. Men en nøgle bliver kopieret alle de steder, hvor systemer skal forbinde poster: integrationer, eksporter, logs, statusfiler tilbage til detailpartnerne, datavarehuset, testdata. Gør et telefonnummer til nøglen, og du har spredt en modtagers personoplysninger ud i hele arkitekturen.
En nøgle skal også være der for hver eneste post: aldrig null eller tom. Hvis nogle mennesker ikke vil eller ikke bør skulle give dig en værdi, kan den værdi ikke være nøglen. Derfor udsteder systemer deres egne interne id’er, og personoplysninger bliver, hvis du overhovedet har brug for dem, en beskyttet attribut.
Så min regel er: unikt, uforanderligt, uden betydning, aldrig personoplysninger.
Naturlige nøgler og surrogatnøgler
Sektion kaldt “Naturlige nøgler og surrogatnøgler ”Databasefolk har navne for noget af det her. En naturlig nøgle findes allerede i forretningens data: en lastbils stelnummer (VIN) er et godt eksempel. Vores applikation har ikke fundet på det, og det har allerede en betydning. En surrogatnøgle bliver oprettet specifikt for at identificere posten; den beskriver ingenting, den identificerer bare.
I de fleste arkitekturer foretrækker jeg en surrogatnøgle som internt post-id og beholder de vigtige naturlige id’er som attributter. Det gør ikke naturlige id’er dårlige; de er ofte ekstremt vigtige. Jeg gør dem bare ikke automatisk til postens unikke id. Spørg, hvad der sker, hvis værdien bliver rettet, omformateret, erstattet, genbrugt, mangler eller kommer fra mere end ét kildesystem. Det er der, en beslutning, der ser enkel ud, bliver til en arkitekturbeslutning.
Én ting kan have flere nyttige id’er
Sektion kaldt “Én ting kan have flere nyttige id’er ”Det interne post-id er ikke nødvendigvis det id, alle andre systemer bruger. Steve Trucking identificerer måske en levering internt med et genereret id. Hver detailpartner kender den samme levering under sit eget ordrenummer: Keystone i sit CSV-manifest, Redrock i sit API, Brightwave i sine EDI-beskeder. Og de otte års historik i RouteDesk, det gamle disponeringsværktøj, bruger RouteDesks egne leverings-id’er.
De id’er betyder noget. Vi skal beholde dem og mappe dem korrekt, for en statusopdatering skal tilbage til hver partner under dens nummer. Men de skal ikke alle sammen være leveringens unikke id. »Hvad er dens id?« kan have mere end ét svar, og arkitekten skal vide, hvilket id der er autoritativt i hvilken sammenhæng. Det vender vi tilbage til med masterdata og integration.
Relationer afhænger af unikke id’er
Sektion kaldt “Relationer afhænger af unikke id’er ”Gå nu tilbage til de streger, vi tegnede. Et manifest oplister leveringer. En modtager modtager leveringer. Et team har teamtildelinger. De relationer virker kun, fordi vi pålideligt kan identificere tingene i begge ender.
Her er, hvor det bider hos Steve Trucking. En detailpartner reviderer sit manifest samme dag: en ordre annulleret, en vare byttet, en ny adresse. Hvis vi ikke kan matche den reviderede linje til den levering, vi allerede har, via partnerens ordrenummer, opretter vi en ekstra levering for det samme køleskab, og et team dukker måske op to gange. Kasser, attributter, nøgler og relationer er ikke separate idéer. De er alle dele af den samme model.
På dette tidspunkt tænker du måske: »Salesforce giver hver post et id.« Korrekt, og det kommer vi til. Hvis dataene bor i Salesforce, får hver post et id genereret af Salesforce. Det er kryptisk og svært at læse, så vi viser som regel også et id-felt, folk kan bruge, som et leveringsnummer D-000184227, et Auto Number-felt. Folk tror ofte, at det nummer er postens id, men det er det ikke: Salesforce-id’et er der stadig nedenunder. Et eksternt system eller en database, Oracle eller SQL Server, har også sine egne unikke id’er. Men arkitekturen kommer måske i sidste ende til at omfatte Salesforce, økonomisystemet (ERP), Snowflake, Data 360, partnernes systemer og systemer, der ikke findes endnu. Den logiske model beskriver forretningens data uden at gøre hver beslutning afhængig af én teknologi. Hvordan Salesforce fysisk implementerer det, er et senere skridt.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”Når jeg gør en konceptuel model til en logisk model, beslutter jeg:
- Hvilke attributter der faktisk beskriver hver entitet.
- Hvordan hver entitet identificeres entydigt, og om det id er stabilt nok til at være dens unikke id.
- Hvilke forretnings-id’er (partneres ordrenumre, gamle id’er) der skal beholdes og mappes.
- Om følsomme oplysninger bliver brugt som nøgle.
- Om relationerne forbinder entiteter via pålidelige unikke id’er.
Vi har nu entiteter, relationer, attributter og unikke id’er: begyndelsen på en rigtig logisk datamodel. Men der er stadig et problem. Det er meget nemt at lægge helt gyldige data det forkerte sted. Det er der, normalisering kommer ind.
Læs mere
Sektion kaldt “Læs mere ”- Custom Field Types (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09): Auto Number giver hver post et unikt nummer med et visningsformat, for eksempel et præfiks og foranstillede nuller; det er ikke postens Salesforce-id. Se også Auto-Number Fields Are Not Always Sequential (opens in a new tab) (på engelsk, kontrolleret 2026-10-09).