Data modelleren naar betekenis
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Studiegids bij hoofdstuk 2 van de cursus Data Architect. Lees eerst de zes modules; deze pagina helpt je na te gaan wat is blijven hangen.
Over deze studiegids. Hij is alleen gebaseerd op de eigen inhoud van deze cursus en op de lijst met doelstellingen in de gepubliceerde examengids van Salesforce. Hij is nooit gebaseerd op echte examenvragen, en hij beweert niet te weten wat er in het examen staat. Als je het examen hebt gedaan, stuur me dan alsjeblieft geen vragen eruit: de certificeringsovereenkomst verbiedt het delen ervan, en antwoorden uit je hoofd leren is sowieso de verkeerde manier om architect te worden.
Dit hoofdstuk is het fundament voor het examenonderdeel Data Modeling and Database Design, een kwart van het examen. Het behandelt het denkwerk; het volgende hoofdstuk, Salesforce-data-architectuur, behandelt hoe het platform het bouwt. Voor het meeste wat over objecten, velden en relaties getoetst wordt, heb je dus beide hoofdstukken nodig.
Voor het examen
Section titled “Voor het examen ”De punten uit dit hoofdstuk die er op het examen het meest toe doen. Elk punt is gekoppeld aan een examendoelstelling en linkt naar de plek waar het behandeld wordt. Vink ze af terwijl je verdergaat.
DM-1: technieken vergelijken voor het ontwerpen van een Salesforce-datamodel
- Ik kan het verschil uitleggen tussen een conceptueel, een logisch en een fysiek datamodel, en waar elk voor dient. (Zet het model om naar Salesforce)
- Ik kan kandidaat-entiteiten in een eis vinden, en een persoon die een taak uitvoert onderscheiden van een stuk data. (Zelfstandige naamwoorden geven je kandidaat-entiteiten)
- Ik kan kraaienpootnotatie lezen en tekenen: één, veel, en de tweede markering voor optioneel of verplicht. (Lees de lijnen, Optionaliteit doet er ook toe)
- Ik kan de kardinaliteit van een relatie benoemen: een-op-een, een-op-veel, veel-op-veel. (Vraag: “één of veel?”)
- Ik weet dat een veel-op-veel-relatie een eigen entiteit wordt, en in Salesforce meestal een koppelobject met twee parents. (Relaties kunnen dingen worden)
- Ik weet wanneer een relatie historie nodig heeft (een record met begin- en einddatum) in plaats van een veld dat overschreven wordt. (De tijd verandert relaties)
- Ik kan een goede unieke ID kiezen, en ik weet waarom een natuurlijke sleutel of iets met persoonsgegevens riskant is. (Dan moeten we het over unieke ID’s hebben)
- Ik ken het verschil tussen een natuurlijke sleutel en een surrogaatsleutel, en weet dat één record meerdere externe identificatoren kan dragen. (Natuurlijke sleutels en surrogaatsleutels)
- Ik weet dat een veld van het type Auto Number een leesbaar nummer is, niet de Salesforce-ID van het record. (Relaties hangen af van unieke ID’s)
- Ik kan de eerste, tweede en derde normaalvorm toepassen, en een veld herkennen dat meerdere waarden bevat of een feit over iets anders herhaalt. (Een simpele manier om naar 1NF, 2NF en 3NF te kijken)
- Ik kan uitleggen wanneer je bewust denormaliseert (gebruikers, rapportage, schaal), en wat het kost. (Ontwerp tot de derde normaalvorm en doe dan een stap terug)
- Ik kan voor een lijst waarden kiezen tussen een keuzelijst en een lookup naar een object. (Lookup of keuzelijst?)
- Ik weet dat een aangepast rapporttype hooguit vier objectrelaties toestaat, en waarom dat ertoe doet bij diepe modellen. (Lookup of keuzelijst?)
- Ik weet wanneer master-detail past (het child krijgt nooit een andere parent) en wanneer een lookup veiliger is, inclusief de richtlijn van Salesforce van niet meer dan 10.000 children op één parent. (Relaties worden platformbeslissingen)
- Ik weet waarom je polymorfe relaties waar mogelijk vermijdt. (Relaties worden platformbeslissingen)
- Ik weet dat een bedrijfsentiteit niet automatisch een aangepast object betekent: het kan een standaardobject zijn, een veld, configuratie, of data die buiten Salesforce staat. (Een bedrijfsentiteit betekent niet automatisch een aangepast object)
Voorbij het examen
Section titled “Voorbij het examen ”Het examen is de vloer, niet het plafond. Dit zijn de gewoonten uit dit hoofdstuk die een architect nodig heeft, of er nu ooit een vraag over gesteld wordt of niet.
- Vergeet Salesforce even. Modelleer de business voordat je haar op account en contactpersoon legt.
- Luister naar het woord dat twee dingen verbergt. Bij Steve Trucking was “klant” een retailpartner en een ontvanger.
- Het model is onderdeel van het gesprek. Je eerste model hoeft niet te kloppen; het moet je laten zien waar je het mis hebt.
- Geef de lijnen een naam. Twee modellen met dezelfde blokken kunnen iets anders betekenen.
- Vraag bij elke relatie: “nu, of door de tijd heen?”
- Uniek, onveranderlijk, betekenisloos, nooit persoonsgegevens.
- Zet een feit waar het hoort, doe dan bewust een stap terug, en schrijf op waarom.
- Denormalisatie haalt complexiteit niet weg; ze verplaatst haar. Weet wie eigenaar is van de waarheid.
- Eén bron van waarheid, veel vormen: schermen, rapporten, het warehouse en AI.
- Ontwerp niet vanuit Setup. Teken het model voordat je op New Custom Object klikt.
- Voer elke fysieke beslissing terug naar iets wat de business nodig heeft.
Begrippen
Section titled “Begrippen ”| Begrip | In één zin |
|---|---|
| Entiteit | Iets waar de business om geeft en gegevens over bijhoudt |
| Kandidaat-entiteit | Een zelfstandig naamwoord dat een entiteit kan worden, als je er eenmaal naar gevraagd hebt |
| Attribuut | Een feit dat een entiteit beschrijft |
| Relatie | Hoe twee entiteiten verbonden zijn, benoemd in de taal van de business |
| Kardinaliteit | Hoeveel van het ene gerelateerd zijn aan hoeveel van het andere |
| Optionaliteit | Of de relatie verplicht is, of nul kan zijn |
| Kraaienpoot | De markering voor “veel” aan het uiteinde van een lijn |
| Koppelobject (junction object) | De manier van Salesforce om een veel-op-veel-relatie te bouwen: een child van beide parents |
| Conceptueel model | Wat er in de business bestaat en hoe het samenhangt; geen Salesforce |
| Logisch model | De data: attributen, unieke ID’s en relaties, nog niet aan een platform gebonden |
| Fysiek model | Hoe het platform het gaat bouwen: objecten, velden en relatietypen |
| Natuurlijke sleutel | Een identificator die al in de business bestaat, zoals het VIN van een vrachtwagen |
| Surrogaatsleutel | Een identificator die alleen gemaakt is om het record te identificeren |
| Externe identificator | De ID van een ander systeem voor hetzelfde record, bewaard en gekoppeld |
| Normalisatie (1NV, 2NV, 3NV) | Elk feit zetten waar het hoort: één waarde per veld, feiten over de hele sleutel, geen feiten over andere feiten |
| Denormalisatie | Data bewust kopiëren of platter maken, om een reden die je kunt benoemen |
| Updateanomalie | Hetzelfde feit op veel plekken opgeslagen, zodat één wijziging sommige kopieën fout laat |
Test jezelf
Section titled “Test jezelf ”Korte scenario’s in de stijl van de cursus. Bepaal je antwoord voordat je het openklapt.
1. Een bedrijf vertelt je dat een ploeg op een vrachtwagen rijdt. Zes weken later vraagt iemand welke ploeg op een bepaalde dag vrachtwagen 117 had. Wat had het model moeten hebben?
Een ploegtoewijzing: de relatie tussen ploeg en vrachtwagen als eigen record, met een begindatum, een einddatum en de route. Ploegen en vrachtwagens zijn door de tijd heen veel-op-veel, en de business geeft om de historie. Een veld op de vrachtwagen was overschreven. Lees opnieuw De tijd verandert relaties.
2. Een team stelt voor het telefoonnummer van elke ontvanger als unieke ID te gebruiken, "omdat het uniek is". Wat zeg je?
Het zakt voor de tests: telefoonnummers veranderen en worden gedeeld, dus het is niet onveranderlijk of betrouwbaar uniek, en het zijn persoonsgegevens die naar elk systeem gekopieerd zouden worden dat naar het record linkt. Gebruik een betekenisloze gegenereerde ID en houd het telefoonnummer als attribuut. Lees opnieuw Dan moeten we het over unieke ID’s hebben.
3. Een levering heeft velden Artikel 1, Artikel 2 en Artikel 3. Er komt een levering met vier artikelen. Wat is het echte probleem, en de oplossing?
Het model verstopte een herhalende structuur in velden (een probleem van de eerste normaalvorm). De oplossing is geen veld Artikel 4; het is een entiteit Leveringsitem, een child van Levering, zodat elk artikel een record is. Lees opnieuw Eerste normaalvorm.
4. Elke levering slaat de naam van de manager van het distributiecentrum op. De manager verandert. Wat ging er mis?
Een feit over iets anders (het distributiecentrum) werd op de levering opgeslagen: een probleem van de derde normaalvorm, en nu een updateanomalie over honderden records. De manager hoort bij het distributiecentrum; de levering verwijst naar het distributiecentrum. Lees opnieuw Derde normaalvorm.
5. Het soort stop (alleen levering, met installatie, met afvoer) heeft een duur, ploegvaardigheden en een checklist nodig. Keuzelijst of object?
Een object. Het heeft meer dan één kolom informatie, wordt door de business beheerd en verandert in zijn eigen tempo. De status van een levering, een korte, stabiele lijst labels, blijft een keuzelijst. Lees opnieuw Lookup of keuzelijst?.
6. Partners willen een scorekaart voor tijdigheid per regio, en de regio staat bij het distributiecentrum. Je kopieert de regio naar elke levering. Wat moet je beslissen?
Wie eigenaar is van de waarheid, hoe de kopie gesynchroniseerd blijft, en of oude leveringen de regio moeten houden die gold toen ze plaatsvonden of het distributiecentrum moeten volgen als dat verhuist. Denormaliseren verplaatste de complexiteit; het haalde haar niet weg. Lees opnieuw Soms wint de rapportage.
7. Een kunstje als Zit kan aan honderdduizenden huisdieren gekoppeld zijn. Master-detail of lookup van Huisdierkunstje naar Kunstje?
Een lookup. De richtlijn van Salesforce is niet meer dan 10.000 children op één parent, en een populair kunstje zou daaroverheen gaan. Master-detail past bij Huisdierkunstje naar Huisdier, omdat het kunstje van een huisdier nooit een andere parent krijgt en één huisdier maar een paar kunstjes kent; het is ook wat het huisdier zijn telling Aantal kunstjes laat samenvatten. Lees opnieuw Zit, Blijf, Modelleer.
Verder lezen
Section titled “Verder lezen ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-09-25): de officiële lijst met doelstellingen en hun gewicht. Kijk altijd de actuele versie na voordat je het examen boekt.