Modeller data for mening
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)
Studieguide for kapittel 2 i kurset Data Architect. Les de seks modulene først; denne siden hjelper deg å sjekke hva som har satt seg.
Om denne studieguiden. Den er bygget bare på kursets eget innhold og på listen over mål i Salesforces publiserte eksamensguide. Den bygger aldri på ekte eksamensspørsmål, og den påstår ikke å vite hva som kommer på eksamen. Hvis du har tatt eksamen, ikke send meg spørsmål fra den: sertifiseringsavtalen forbyr å dele dem, og å pugge svar er uansett feil måte å bli arkitekt på.
Dette kapitlet er grunnlaget for eksamensdelen Data Modeling and Database Design, som utgjør en fjerdedel av eksamen. Det dekker tankegangen; neste kapittel, Dataarkitektur i Salesforce, dekker hvordan plattformen bygger det. Så det meste av det som testes om objekter, felt og relasjoner, trenger begge kapitlene.
Til eksamen
Section titled “Til eksamen ”Punktene fra dette kapitlet som mest sannsynlig betyr noe på eksamen. Hvert av dem er knyttet til sitt eksamensmål og lenker til der det undervises. Kryss av etter hvert.
DM-1: sammenligne teknikker for å designe en datamodell i Salesforce
- Jeg kan forklare forskjellen på en konseptuell, en logisk og en fysisk datamodell, og hva hver av dem er til for. (Gjør modellen om til Salesforce)
- Jeg kan finne kandidatentiteter i et krav og skille en person som gjør en jobb, fra en bit data. (Substantiver gir deg kandidatentiteter)
- Jeg kan lese og tegne kråkefotnotasjon: én, mange, og det andre merket for valgfri eller påkrevd. (Les linjene, Valgfrihet betyr også noe)
- Jeg kan angi en relasjons kardinalitet: én-til-én, én-til-mange, mange-til-mange. (Spør «én eller mange?»)
- Jeg vet at en mange-til-mange-relasjon blir en egen entitet, og i Salesforce vanligvis et koblingsobjekt (junction object) med to overordnede. (Relasjoner kan bli ting)
- Jeg vet når en relasjon trenger historikk (en post med start- og sluttdato) i stedet for et felt som blir skrevet over. (Tiden endrer relasjoner)
- Jeg kan velge en god unik ID, og jeg vet hvorfor en naturlig nøkkel eller noe med personopplysninger er et risikabelt valg. (Så må vi snakke om unike ID-er)
- Jeg kjenner forskjellen på en naturlig nøkkel og en surrogatnøkkel, og vet at én post kan ha flere eksterne ID-er. (Naturlige nøkler og surrogatnøkler)
- Jeg vet at et Auto Number-felt er et lesbart nummer, ikke postens Salesforce-ID. (Relasjoner er avhengige av unike ID-er)
- Jeg kan bruke første, andre og tredje normalform, og oppdage et felt som inneholder flere verdier eller gjentar et faktum om noe annet. (En enkel måte å tenke på 1NF, 2NF og 3NF)
- Jeg kan forklare når jeg skal denormalisere med vilje (brukere, rapportering, skala), og hva det koster. (Design til tredje normalform, og trekk deg så litt tilbake)
- Jeg kan velge mellom en plukkliste og en lookup til et objekt for en verdiliste. (Lookup eller plukkliste?)
- Jeg vet at en egendefinert rapporttype tillater høyst fire objektrelasjoner, og hvorfor det betyr noe for dype modeller. (Lookup eller plukkliste?)
- Jeg vet når master-detail passer (det underordnede får aldri en ny overordnet) og når en lookup er tryggere, inkludert Salesforces anbefaling om høyst 10 000 underordnede på én overordnet. (Relasjoner blir plattformbeslutninger)
- Jeg vet hvorfor jeg bør unngå polymorfe relasjoner der jeg kan. (Relasjoner blir plattformbeslutninger)
- Jeg vet at en forretningsentitet ikke automatisk betyr et egendefinert objekt: det kan være et standardobjekt, et felt, konfigurasjon eller data som bor utenfor Salesforce. (En forretningsentitet betyr ikke automatisk et egendefinert objekt)
Utover eksamen
Section titled “Utover eksamen ”Eksamen er gulvet, ikke taket. Dette er vanene fra kapitlet som en arkitekt trenger, enten et spørsmål noen gang spør om dem eller ikke.
- Glem Salesforce et øyeblikk. Modeller virksomheten før du kobler den til konto (Account) og kontakt (Contact).
- Lytt etter ordet som skjuler to ting. Hos Steve Trucking var «kunde» både en detaljhandelspartner og en mottaker.
- Modellen er en del av samtalen. Den første modellen din skal ikke ha rett; den skal vise deg hvor du tar feil.
- Gi linjene navn. To modeller med de samme boksene kan bety forskjellige ting.
- Spør «nå, eller over tid?» om hver relasjon.
- Unik, uforanderlig, uten mening, aldri PII.
- Plasser et faktum der det hører hjemme, trekk deg så tilbake med vilje, og skriv ned hvorfor.
- Denormalisering fjerner ikke kompleksitet; den flytter den. Vit hvem som eier sannheten.
- Én sannhetskilde, mange former: skjermer, rapporter, datavarehuset og KI (AI).
- Ikke design fra Setup. Tegn modellen før du klikker New Custom Object.
- Spor hver fysiske beslutning tilbake til noe virksomheten trenger.
Ord du bør kunne
Section titled “Ord du bør kunne ”| Begrep | På én linje |
|---|---|
| Entitet | En ting virksomheten bryr seg om og holder data om |
| Kandidatentitet | Et substantiv som kan bli en entitet, når du har spurt om det |
| Attributt | Et faktum som beskriver en entitet |
| Relasjon | Hvordan to entiteter henger sammen, navngitt med forretningsspråk |
| Kardinalitet | Hvor mange av den ene som henger sammen med hvor mange av den andre |
| Valgfrihet (optionality) | Om relasjonen er påkrevd, eller kan være null |
| Kråkefot | Merket for «mange» i enden av en linje |
| Koblingsobjekt (junction object) | Salesforces måte å bygge en mange-til-mange-relasjon på: et underordnet objekt til begge de overordnede |
| Konseptuell modell | Hva som finnes i virksomheten og hvordan det henger sammen; ingen Salesforce |
| Logisk modell | Dataene: attributter, unike ID-er og relasjoner, fortsatt ikke knyttet til en plattform |
| Fysisk modell | Hvordan plattformen skal bygge det: objekter, felt og relasjonstyper |
| Naturlig nøkkel | En ID som allerede finnes i virksomheten, som en lastebils VIN |
| Surrogatnøkkel | En ID som er laget bare for å identifisere posten |
| Ekstern ID | Et annet systems ID for den samme posten, tatt vare på og koblet |
| Normalisering (1NF, 2NF, 3NF) | Å plassere hvert faktum der det hører hjemme: én verdi per felt, fakta om hele nøkkelen, ingen fakta om andre fakta |
| Denormalisering | Å kopiere eller flate ut data med vilje, av en grunn du kan sette navn på |
| Oppdateringsanomali | Det samme faktumet lagret mange steder, så én endring etterlater noen kopier feil |
Test deg selv
Section titled “Test deg selv ”Korte scenarioer i kursets stil. Bestem deg for svaret før du åpner det.
1. En virksomhet forteller deg at et team kjører en lastebil. Seks uker senere spør noen hvilket team som hadde lastebil 117 en bestemt dag. Hva burde modellen ha hatt?
En teamtildeling (Crew Assignment): relasjonen mellom team og lastebil som en egen post, med startdato, sluttdato og rute. Team og lastebiler er mange-til-mange over tid, og virksomheten bryr seg om historikken. Et felt på lastebilen ville blitt skrevet over. Les Tiden endrer relasjoner på nytt.
2. Et team foreslår å bruke telefonnummeret til hver mottaker som unik ID, «fordi det er unikt». Hva sier du?
Det stryker på testene: telefonnumre endres og deles, så det er verken uforanderlig eller pålitelig unikt, og det er personopplysninger som ville blitt kopiert inn i hvert system som kobler seg til posten. Bruk en generert ID uten mening, og behold telefonnummeret som et attributt. Les Så må vi snakke om unike ID-er på nytt.
3. En levering har feltene Vare 1, Vare 2 og Vare 3. En levering med fire varer kommer inn. Hva er det egentlige problemet, og hva er løsningen?
Modellen skjulte en gjentatt struktur inni felt (et problem med første normalform). Løsningen er ikke et Vare 4-felt; det er en leveringslinje-entitet (Delivery Item), underordnet levering, slik at hver vare er en post. Les Første normalform på nytt.
4. Hver levering lagrer navnet på lederen for distribusjonssenteret. Lederen byttes ut. Hva gikk galt?
Et faktum om noe annet (distribusjonssenteret) ble lagret på leveringen: et problem med tredje normalform, og nå en oppdateringsanomali over hundrevis av poster. Lederen hører hjemme hos distribusjonssenteret; leveringen peker på distribusjonssenteret. Les Tredje normalform på nytt.
5. Typen stopp (bare levering, med installasjon, med bortkjøring) trenger en varighet, ferdigheter i teamet og en sjekkliste. Plukkliste eller objekt?
Et objekt. Det har mer enn én kolonne med informasjon, det forvaltes av virksomheten, og det endrer seg i sitt eget tempo. Statusen til en levering, en kort, stabil liste med etiketter, forblir en plukkliste. Les Lookup eller plukkliste? på nytt.
6. Partnerne vil ha et resultatkort for levering i tide per region, og regionen bor på distribusjonssenteret. Du kopierer regionen over på hver levering. Hva må du bestemme?
Hvem som eier sannheten, hvordan kopien holdes synkronisert, og om gamle leveringer skal beholde regionen som var sann da de skjedde, eller følge distribusjonssenteret hvis det flytter. Denormaliseringen flyttet kompleksiteten; den fjernet den ikke. Les Noen ganger vinner rapporteringen på nytt.
7. Et triks som Sitt kan bli koblet til hundretusener av kjæledyr. Master-detail eller lookup fra Kjæledyrtriks til Triks?
En lookup. Salesforces anbefaling er høyst 10 000 underordnede på én overordnet, og et populært triks ville passert det. Master-detail passer fra Kjæledyrtriks til Kjæledyr, fordi et kjæledyrs triks aldri får en ny overordnet og ett kjæledyr bare kan noen få triks; det er også det som lar kjæledyret summere opp antallet Kjente triks. Les Sitt, bli, modellér på nytt.
Les mer
Section titled “Les mer ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-09-25): den offisielle listen over mål og vektingen deres. Sjekk alltid gjeldende versjon før du bestiller eksamen.