Modellera data för mening
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)
Studieguide för kapitel 2 i kursen Data Architect. Läs de sex modulerna först; den här sidan hjälper dig att kontrollera vad som har fastnat.
Om den här studieguiden. Den bygger enbart på kursens eget innehåll och på listan över mål i provguiden som Salesforce publicerar. Den bygger aldrig på verkliga provfrågor, och den gör inga anspråk på att veta vad som kommer på provet. Om du har skrivit provet: skicka inte frågor från det till mig. Certifieringsavtalet förbjuder att de delas, och att memorera svar är ändå fel sätt att bli arkitekt.
Det här kapitlet är grunden för provets avsnitt Data Modeling and Database Design, som är en fjärdedel av provet. Det täcker tänkandet; nästa kapitel, Dataarkitektur i Salesforce, täcker hur plattformen bygger det. Så det mesta som testas om objekt, fält och relationer kräver båda kapitlen.
Inför provet
Section titled “Inför provet ”De punkter från det här kapitlet som mest sannolikt spelar roll på provet. Var och en är knuten till sitt provmål och länkar till där den lärs ut. Bocka av dem allteftersom.
DM-1: att jämföra tekniker för att designa en datamodell i Salesforce
- Jag kan förklara skillnaden mellan en konceptuell, en logisk och en fysisk datamodell, och vad var och en är till för. (Gör modellen till Salesforce)
- Jag kan hitta kandidatentiteter i ett krav, och skilja en person som utför ett jobb från en bit data. (Substantiv ger dig kandidatentiteter)
- Jag kan läsa och rita kråkfotsnotation (crow’s foot): en, många, och den andra markeringen för valfri eller obligatorisk. (Läs linjerna, Valfrihet spelar också roll)
- Jag kan ange en relations kardinalitet: en-till-en, en-till-många, många-till-många. (Fråga ”en eller många?”)
- Jag vet att en många-till-många-relation blir en egen entitet, och i Salesforce oftast ett kopplingsobjekt (junction object) med två föräldrar. (Relationer kan bli saker)
- Jag vet när en relation behöver historik (en post med start- och slutdatum) i stället för ett fält som skrivs över. (Tiden ändrar relationer)
- Jag kan välja ett bra unikt ID, och jag vet varför en naturlig nyckel eller något med personuppgifter är riskabelt. (Sedan måste vi prata om unika ID:n)
- Jag vet skillnaden mellan en naturlig nyckel och en surrogatnyckel, och att en post kan bära flera externa ID:n. (Naturliga nycklar och surrogatnycklar)
- Jag vet att ett Auto Number-fält är ett läsbart nummer, inte postens Salesforce-ID. (Relationer är beroende av unika ID:n)
- Jag kan tillämpa första, andra och tredje normalformen, och upptäcka ett fält som innehåller flera värden eller upprepar ett faktum om något annat. (Ett enkelt sätt att tänka på 1NF, 2NF och 3NF)
- Jag kan förklara när man medvetet denormaliserar (användare, rapportering, skala), och vad det kostar. (Designa till tredje normalformen, backa sedan)
- Jag kan välja mellan en plocklista och en lookup till ett objekt för en lista med värden. (Lookup eller plocklista?)
- Jag vet att en anpassad rapporttyp tillåter högst fyra objektrelationer, och varför det spelar roll för djupa modeller. (Lookup eller plocklista?)
- Jag vet när master-detail passar (barnet byter aldrig förälder) och när en lookup är säkrare, inklusive rekommendationen från Salesforce om högst 10 000 barn på en förälder. (Relationer blir plattformsbeslut)
- Jag vet varför jag ska undvika polymorfa relationer där jag kan. (Relationer blir plattformsbeslut)
- Jag vet att en affärsentitet inte automatiskt betyder ett anpassat objekt: den kan vara ett standardobjekt, ett fält, konfiguration eller data som bor utanför Salesforce. (En affärsentitet betyder inte automatiskt ett anpassat objekt)
Bortom provet
Section titled “Bortom provet ”Provet är golvet, inte taket. Det här är vanorna från kapitlet som en arkitekt behöver, oavsett om någon fråga någonsin handlar om dem.
- Glöm Salesforce en stund. Modellera verksamheten innan du mappar den till konto och kontakt.
- Lyssna efter ordet som döljer två saker. Hos Steve Trucking var ”kund” både en detaljhandelspartner och en mottagare.
- Modellen är en del av samtalet. Din första modell är inte tänkt att vara rätt; den är tänkt att visa dig var du har fel.
- Namnge linjerna. Två modeller med samma rutor kan betyda olika saker.
- Fråga ”nu, eller över tid?” om varje relation.
- Unikt, oföränderligt, betydelselöst, aldrig personuppgifter.
- Lägg ett faktum där det hör hemma, backa sedan medvetet, och skriv ner varför.
- Denormalisering tar inte bort komplexitet; den flyttar den. Vet vem som äger sanningen.
- En sanningskälla, många former: skärmbilder, rapporter, datalagret och AI.
- Designa inte från Setup. Rita modellen innan du klickar på New Custom Object.
- Spåra varje fysiskt beslut bakåt till något som verksamheten behöver.
Ord att kunna
Section titled “Ord att kunna ”| Term | På en rad |
|---|---|
| Entitet | En sak som verksamheten bryr sig om och sparar data om |
| Kandidatentitet | Ett substantiv som kan bli en entitet, när du väl har frågat om det |
| Attribut | Ett faktum som beskriver en entitet |
| Relation | Hur två entiteter hänger ihop, namngiven på verksamhetens språk |
| Kardinalitet | Hur många av den ena som hör ihop med hur många av den andra |
| Valfrihet (optionality) | Om relationen är obligatorisk, eller kan vara noll |
| Kråkfot (crow’s foot) | Markeringen för ”många” i änden av en linje |
| Kopplingsobjekt (junction object) | Sättet i Salesforce att bygga en många-till-många-relation: ett barn till båda föräldrarna |
| Konceptuell modell | Vad som finns i verksamheten och hur det hänger ihop; ingen Salesforce |
| Logisk modell | Data: attribut, unika ID:n och relationer, fortfarande inte bundna till en plattform |
| Fysisk modell | Hur plattformen ska bygga det: objekt, fält och relationstyper |
| Naturlig nyckel | Ett ID som redan finns i verksamheten, som en lastbils VIN |
| Surrogatnyckel | Ett ID som skapas enbart för att identifiera posten |
| Externt ID | Ett annat systems ID för samma post, som behålls och mappas |
| Normalisering (1NF, 2NF, 3NF) | Att lägga varje faktum där det hör hemma: ett värde per fält, fakta om hela nyckeln, inga fakta om andra fakta |
| Denormalisering | Att medvetet kopiera eller platta till data, av ett skäl du kan namnge |
| Uppdateringsanomali | Samma faktum lagrat på många ställen, så att en ändring lämnar vissa kopior fel |
Testa dig själv
Section titled “Testa dig själv ”Korta scenarier i kursens stil. Bestäm ditt svar innan du öppnar det.
1. En verksamhet berättar att ett team kör en lastbil. Sex veckor senare frågar någon vilket team som hade lastbil 117 en viss dag. Vad borde modellen ha haft?
En teamtilldelning (Crew Assignment): relationen mellan team och lastbil som en egen post, med ett startdatum, ett slutdatum och rutten. Team och lastbilar är många-till-många över tid, och verksamheten bryr sig om historiken. Ett fält på lastbilen skulle ha skrivits över. Läs om Tiden ändrar relationer.
2. Ett team föreslår att varje mottagares telefonnummer ska användas som unikt ID, ”för att det är unikt”. Vad säger du?
Det klarar inte testerna: telefonnummer ändras och delas, så det är varken oföränderligt eller pålitligt unikt, och det är personuppgifter som skulle kopieras in i varje system som länkar till posten. Använd ett betydelselöst genererat ID och behåll telefonnumret som ett attribut. Läs om Sedan måste vi prata om unika ID:n.
3. En leverans har fälten Vara 1, Vara 2 och Vara 3. En leverans med fyra varor kommer in. Vad är det egentliga problemet, och vad är lösningen?
Modellen gömde en upprepad struktur i fält (ett problem med första normalformen). Lösningen är inte ett fält Vara 4; det är en entitet leveransrad (Delivery Item), ett barn till leveransen, så att varje vara är en post. Läs om Första normalformen.
4. Varje leverans lagrar namnet på distributionscentralens chef. Chefen byts ut. Vad gick fel?
Ett faktum om något annat (distributionscentralen) lagrades på leveransen: ett problem med tredje normalformen, och nu en uppdateringsanomali över hundratals poster. Chefen hör hemma hos distributionscentralen; leveransen pekar på distributionscentralen. Läs om Tredje normalformen.
5. Typen av stopp (bara leverans, med installation, med bortforsling) behöver en varaktighet, teamets färdigheter och en checklista. Plocklista eller objekt?
Ett objekt. Det har mer än en kolumn med information, det förvaltas av verksamheten och det ändras i sin egen takt. En leverans status, en kort, stabil lista med etiketter, förblir en plocklista. Läs om Lookup eller plocklista?.
6. Partnerna vill ha ett scorecard för leveranser i tid per region, och regionen bor på distributionscentralen. Du kopierar regionen till varje leverans. Vad måste du bestämma?
Vem som äger sanningen, hur kopian hålls synkad, och om gamla leveranser ska behålla den region som var sann när de skedde eller följa distributionscentralen om den flyttar. Denormaliseringen flyttade komplexiteten; den tog inte bort den. Läs om Ibland vinner rapporteringen.
7. Ett trick som Sitt kan kopplas till hundratusentals husdjur. Master-detail eller lookup från Husdjurstrick till Trick?
En lookup. Rekommendationen från Salesforce är högst 10 000 barn på en förälder, och ett populärt trick skulle gå över den. Master-detail passar från Husdjurstrick till Husdjur, eftersom ett husdjurs trick aldrig byter förälder och ett husdjur bara kan några få trick; det är också det som låter husdjuret sammanställa sin räknare Kända trick. Läs om Sitt, stanna, modellera.
Utforska vidare
Section titled “Utforska vidare ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-09-25): den officiella listan över mål och deras vikter. Kontrollera alltid den aktuella versionen innan du bokar provet.