Modellér data for betydning
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)
Studieguide til kapitel 2 i kurset Data Architect. Læs de seks moduler først; denne side hjælper dig med at tjekke, hvad der er blevet hængende.
Om denne studieguide. Den er udelukkende bygget på kursets eget indhold og listen over mål i Salesforces offentliggjorte eksamensguide. Den bygger aldrig på rigtige eksamensspørgsmål, og den påstår ikke at vide, hvad der kommer til eksamen. Hvis du har taget eksamen, så send mig venligst ikke spørgsmål fra den: certificeringsaftalen forbyder at dele dem, og at lære svar udenad er under alle omstændigheder den forkerte måde at blive arkitekt på.
Dette kapitel er grundlaget for eksamens afsnit om datamodellering og databasedesign (Data Modeling and Database Design), som udgør en fjerdedel af eksamen. Det dækker tankegangen; det næste kapitel, Dataarkitektur i Salesforce, dækker, hvordan platformen bygger det. Så det meste af det, der testes om objekter, felter og relationer, kræver begge kapitler.
Til eksamen
Sektion kaldt “Til eksamen ”De punkter fra dette kapitel, der mest sandsynligt betyder noget til eksamen. Hvert punkt er knyttet til sit eksamensmål og linker til det sted, hvor det gennemgås. Sæt flueben, efterhånden som du kommer frem.
DM-1: sammenligne teknikker til at designe en datamodel i Salesforce
- Jeg kan forklare forskellen på en konceptuel, en logisk og en fysisk datamodel, og hvad hver af dem er til. (Gør modellen til Salesforce)
- Jeg kan finde kandidater til entiteter i et krav og kende forskel på en person, der udfører et job, og et stykke data. (Navneord giver dig kandidater til entiteter)
- Jeg kan læse og tegne kragefodsnotation: én, mange og den anden markering for valgfri eller påkrævet. (Læs stregerne, Optionalitet betyder også noget)
- Jeg kan angive en relations kardinalitet: én-til-én, én-til-mange, mange-til-mange. (Spørg »én eller mange?«)
- Jeg ved, at en mange-til-mange-relation bliver en entitet for sig, og i Salesforce som regel et forbindelsesobjekt (junction object) med to forældre. (Relationer kan blive til ting)
- Jeg ved, hvornår en relation har brug for historik (en post med start- og slutdato) i stedet for et felt, der bliver overskrevet. (Tiden ændrer relationer)
- Jeg kan vælge et godt unikt id, og jeg ved, hvorfor en naturlig nøgle eller noget med personoplysninger er et risikabelt valg. (Så må vi tale om unikke id’er)
- Jeg kender forskellen på en naturlig nøgle og en surrogatnøgle, og jeg ved, at én post kan bære flere eksterne id’er. (Naturlige nøgler og surrogatnøgler)
- Jeg ved, at et Auto Number-felt er et læsbart nummer, ikke postens Salesforce-id. (Relationer afhænger af unikke id’er)
- Jeg kan anvende første, anden og tredje normalform og få øje på et felt, der indeholder flere værdier eller gentager en kendsgerning om noget andet. (En enkel måde at tænke på 1NF, 2NF og 3NF)
- Jeg kan forklare, hvornår man med vilje skal denormalisere (brugere, rapportering, skala), og hvad det koster. (Design til tredje normalform, og træd så et skridt tilbage)
- Jeg kan vælge mellem en valgliste og en lookup-relation til et objekt for en liste af værdier. (Lookup eller valgliste?)
- Jeg ved, at en brugerdefineret rapporttype højst tillader fire objektrelationer, og hvorfor det betyder noget for dybe modeller. (Lookup eller valgliste?)
- Jeg ved, hvornår master-detail passer (barnet får aldrig en ny forælder), og hvornår en lookup-relation er sikrere, herunder Salesforces anbefaling om højst 10.000 børn på én forælder. (Relationer bliver til platformsbeslutninger)
- Jeg ved, hvorfor jeg skal undgå polymorfe relationer, hvor jeg kan. (Relationer bliver til platformsbeslutninger)
- Jeg ved, at en forretningsentitet ikke automatisk betyder et brugerdefineret objekt: det kan være et standardobjekt, et felt, konfiguration eller data, der bor uden for Salesforce. (En forretningsentitet betyder ikke automatisk et brugerdefineret objekt)
Ud over eksamen
Sektion kaldt “Ud over eksamen ”Eksamen er gulvet, ikke loftet. Det her er de vaner fra kapitlet, som en arkitekt har brug for, uanset om et spørgsmål nogensinde spørger til dem.
- Glem Salesforce et øjeblik. Modellér forretningen, før du mapper den til konto og kontakt.
- Lyt efter det ord, der skjuler to ting. Hos Steve Trucking var »kunde« både en detailpartner og en modtager.
- Modellen er en del af samtalen. Din første model skal ikke have ret; den skal vise dig, hvor du tager fejl.
- Giv stregerne navne. To modeller med de samme kasser kan betyde forskellige ting.
- Spørg »nu eller over tid?« om hver relation.
- Unikt, uforanderligt, uden betydning, aldrig personoplysninger.
- Placér en kendsgerning, hvor den hører hjemme, træd så et skridt tilbage med vilje, og skriv ned hvorfor.
- Denormalisering fjerner ikke kompleksitet; den flytter den. Vid, hvem der ejer sandheden.
- Én sandhedskilde, mange former: skærme, rapporter, datavarehuset og AI.
- Design ikke ud fra Setup. Tegn modellen, før du klikker på New Custom Object.
- Før hver fysisk beslutning tilbage til noget, forretningen har brug for.
Ord du skal kende
Sektion kaldt “Ord du skal kende ”| Term | På én linje |
|---|---|
| Entitet | En ting, forretningen går op i og gemmer data om |
| Kandidat til entitet | Et navneord, der måske bliver en entitet, når du har spurgt til det |
| Attribut | En kendsgerning, der beskriver en entitet |
| Relation | Hvordan to entiteter er forbundet, navngivet i forretningens sprog |
| Kardinalitet | Hvor mange af den ene der hænger sammen med hvor mange af den anden |
| Optionalitet | Om relationen er påkrævet, eller om den kan være nul |
| Kragefod | Markeringen for »mange« for enden af en streg |
| Forbindelsesobjekt (junction object) | Salesforces måde at bygge en mange-til-mange-relation på: et barn af begge forældre |
| Konceptuel model | Hvad der findes i forretningen, og hvordan det hænger sammen; ingen Salesforce |
| Logisk model | Dataene: attributter, unikke id’er og relationer, stadig ikke bundet til en platform |
| Fysisk model | Hvordan platformen vil bygge det: objekter, felter og relationstyper |
| Naturlig nøgle | Et id, der allerede findes i forretningen, som en lastbils stelnummer (VIN) |
| Surrogatnøgle | Et id, der kun er oprettet for at identificere posten |
| Eksternt id | Et andet systems id for den samme post, beholdt og mappet |
| Normalisering (1NF, 2NF, 3NF) | At placere hver kendsgerning, hvor den hører hjemme: én værdi pr. felt, kendsgerninger om hele nøglen, ingen kendsgerninger om andre kendsgerninger |
| Denormalisering | At kopiere eller flade data ud med vilje, af en grund, du kan sætte ord på |
| Opdateringsanomali | Den samme kendsgerning gemt mange steder, så én ændring efterlader nogle kopier forkerte |
Test dig selv
Sektion kaldt “Test dig selv ”Korte scenarier i kursets stil. Beslut dit svar, før du åbner det.
1. En virksomhed fortæller dig, at et team kører en lastbil. Seks uger senere spørger nogen, hvilket team der havde lastbil 117 på en bestemt dag. Hvad burde modellen have haft?
En teamtildeling: relationen mellem team og lastbil som en post for sig med en startdato, en slutdato og ruten. Teams og lastbiler er mange-til-mange over tid, og forretningen går op i historikken. Et felt på lastbilen ville være blevet overskrevet. Læs Tiden ændrer relationer igen.
2. Et team foreslår at bruge hver modtagers telefonnummer som unikt id, »fordi det er unikt«. Hvad siger du?
Det dumper testene: telefonnumre ændrer sig og bliver delt, så det er hverken uforanderligt eller pålideligt unikt, og det er personoplysninger, som ville blive kopieret ind i hvert system, der linker til posten. Brug et genereret id uden betydning, og behold telefonnummeret som en attribut. Læs Så må vi tale om unikke id’er igen.
3. En levering har felterne Vare 1, Vare 2 og Vare 3. Der kommer en levering med fire varer. Hvad er det egentlige problem, og hvad er løsningen?
Modellen gemte en gentagen struktur inde i felter (et problem med første normalform). Løsningen er ikke et Vare 4-felt; det er en leveringslinje-entitet, et barn af levering, så hver vare er en post. Læs Første normalform igen.
4. Hver levering gemmer navnet på distributionscentrets leder. Lederen bliver udskiftet. Hvad gik galt?
En kendsgerning om noget andet (distributionscentret) blev gemt på leveringen: et problem med tredje normalform og nu en opdateringsanomali på tværs af hundredvis af poster. Lederen hører til distributionscentret; leveringen peger på distributionscentret. Læs Tredje normalform igen.
5. Typen af stop (kun levering, med installation, med bortkørsel) har brug for en varighed, teamets færdigheder og en tjekliste. Valgliste eller objekt?
Et objekt. Det har mere end én kolonne med information, det administreres af forretningen, og det ændrer sig i sit eget tempo. En leverings status, en kort, stabil liste af etiketter, forbliver en valgliste. Læs Lookup eller valgliste? igen.
6. Partnerne vil have et scorecard for rettidighed pr. region, og regionen bor på distributionscentret. Du kopierer regionen over på hver levering. Hvad skal du beslutte?
Hvem der ejer sandheden, hvordan kopien holdes synkroniseret, og om gamle leveringer skal beholde den region, der var sand, da de fandt sted, eller følge distributionscentret, hvis det flytter. Denormaliseringen flyttede kompleksiteten; den fjernede den ikke. Læs Nogle gange vinder rapporteringen igen.
7. Et trick som Sit kan blive knyttet til hundredtusindvis af kæledyr. Master-detail eller lookup fra Kæledyrstrick til Trick?
En lookup-relation. Salesforces anbefaling er højst 10.000 børn på én forælder, og et populært trick ville komme over det. Master-detail passer fra Kæledyrstrick til Kæledyr, fordi et kæledyrs trick aldrig får en ny forælder, og ét kæledyr kun kan nogle få tricks; det er også det, der lader kæledyret samle sit Kendte tricks-antal i et oversigtsfelt. Læs Sit, bliv, modellér igen.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-09-25): den officielle liste over mål og deres vægtning. Tjek altid den aktuelle version, før du booker eksamen.