Bouw het logische model
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)
Module 3 van 6 in het hoofdstuk Data modelleren naar betekenis, hoofdstuk 2 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Teken de relaties · Volgende: Zet data waar die hoort
De vraag die deze module beantwoordt: Hoe maak ik van een conceptueel model een logisch datamodel?
Het conceptuele model vertelde ons wat er bij Steve Trucking bestaat en hoe het samenhangt: retailpartners en hun distributiecentra, vrachtlijsten en leveringen, ontvangers, routes en stops, ploegen, vrachtwagens en ploegtoewijzingen. Dat is genoeg voor een heel productief gesprek met de business. Maar uiteindelijk heb ik meer detail nodig. Wat moeten we over een levering weten? Wat maakt het ene distributiecentrum anders dan het andere? Hoe identificeren we een ontvanger? Wat hoort bij een ploegtoewijzing in plaats van bij de ploeg of de vrachtwagen? Die vragen brengen ons van een conceptueel model naar een logisch datamodel, en we bouwen nog steeds geen Salesforce.
Zit, Blijf, Modelleer
Section titled “Zit, Blijf, Modelleer ”Eerst terug naar de honden. We hebben de vakjes en de lijnen. Nu twee nieuwe vragen: wat weten we over elk ding, en hoe houden we ze uit elkaar?
Wat beschrijft het? Een hond heeft een naam en een geboortedatum. Een eigenaar heeft een naam, een telefoonnummer en een adres. Een kunstje heeft een naam en een moeilijkheidsgraad. Elk feit komt op het vakje dat het beschrijft.
Dan het koppelobject. Hoe goed Bella Zit doet, en wanneer ze het leerde: beschrijft dat Bella? Niet helemaal; ze is beter in sommige kunstjes dan in andere. Beschrijft het Zit? Nee; elke hond doet Zit anders. Het beschrijft Bella en Zit samen, dus het hoort op het Hondkunstje: het niveau en de datum waarop ze het leerde. Daarom bestaat het koppelobject: sommige feiten horen alleen bij het paar.
Welke hond is welke? Probeer eerst de naam. Er zijn heel veel honden die Max heten, dus de naam is niet uniek. Het telefoonnummer van de eigenaar? Marcus heeft twee honden op hetzelfde nummer, mensen veranderen van nummer, en het is iemands persoonsgegeven, dat gekopieerd zou worden naar elk systeem dat ooit naar een hond verwijst. Het chipnummer ziet er beter uit: het is uniek, en het verandert niet. Maar een nieuwe pup is misschien nog niet gechipt, en een sleutel mag niet leeg zijn. Dus het chipnummer blijft, als iets waaronder de hond ook bekend is, en de hond krijgt een eigen Hond-ID: een nummer dat één saaie taak doet, de ene hond van de andere onderscheiden.
Dat zijn dezelfde vragen die we nu aan Steve Trucking stellen, en de redenen waarom de naam, de telefoon en het chipnummer elk tekortschieten, worden een regel die ik al jaren aanhoud.
Conceptueel zegt wat er bestaat; logisch zegt wat het als data betekent
Section titled “Conceptueel zegt wat er bestaat; logisch zegt wat het als data betekent ”Neem Vrachtwagen. Wat moet ik over een vrachtwagen weten? Misschien het eenheidsnummer, het VIN, het merk, het model, het bouwjaar, het kenteken, de huidige kilometerstand en de status. Dat zijn attributen van Vrachtwagen.
Neem nu Levering. Misschien het ordernummer van de retailpartner, de bezorgdatum, het beloofde tijdvak, het werkelijke aankomsttijdstip, de status, en of er een installatie of afvoer bij hoort. Ook weer attributen.
Het conceptuele model vertelde ons dat Levering bestaat. Het logische model begint te vertellen wat een levering als data betekent. Een simpel blok als Vrachtwagen of Levering kan voor een hele reeks velden staan.
Toch blijven de blokken in de meeste van onze diagrammen eenvoudig, om drie redenen. Het aantal velden groeit. Velden raken snel verouderd. En elk veld heeft details die moeilijk in een objectmodel te tonen zijn: de API-naam, het label, het gegevenstype en de lengte. Die details worden zeker vastgelegd, alleen niet in het eerste datamodel. Als een paar sleutelvelden echt helpen het verhaal te vertellen, teken ik een gedetailleerd datamodel: een gerichte uitsnede, met alleen de velden die voor het punt belangrijk zijn.
Attributen moeten de entiteit beschrijven
Section titled “Attributen moeten de entiteit beschrijven ”Hier is een simpele vraag die ik stel als ik naar een attribuut kijk: wat beschrijft dit? Het merk van de vrachtwagen beschrijft duidelijk de vrachtwagen. Maar hoe zit het met de namen van de ploegleden op een levering? Beschrijven die de levering? Of beschrijven ze een ploeg, die een ploegtoewijzing had, die de route dekte, waarop deze stop stond?
Hier begint een datamodel dingen bloot te leggen die op een scherm volkomen redelijk lijken. Een coördinator zegt: “Ik wil de namen van de ploeg op de levering zien.” Dat is een geldige eis voor de gebruikerservaring. Het is niet per se een eis om de namen van de ploeg op de levering op te slaan. Dat zijn twee verschillende dingen, en we komen erop terug bij normalisatie. Wen er voor nu aan om te vragen welk ding dit feit eigenlijk beschrijft. Die vraag bespaart je veel ellende.
Dan moeten we het over unieke ID’s hebben
Section titled “Dan moeten we het over unieke ID’s hebben ”Attributen beschrijven dingen. Maar er is nog een probleem op te lossen: hoe weet ik welk ding welk is?
Twee ontvangers heten Jan Smit. Zijn het dezelfde persoon? Misschien; misschien niet. Een naam is niet genoeg. Een adres? Mensen verhuizen. Telefoonnummers veranderen. E-mailadressen veranderen. Zelfs de naam van een retailpartner kan veranderen.
Dat brengt ons bij sleutels: wat ons in staat stelt iets in ons model uniek te identificeren. Het is een gebied waarover ik in de loop der jaren een vrij sterke mening heb ontwikkeld. Voor een identificator wil ik vier dingen:
Uniek. Onveranderlijk. Betekenisloos. Nooit persoonsgegevens.
Uniek. Een identificator moet precies één ding identificeren. Als twee leveringen dezelfde waarde kunnen hebben, is het geen betrouwbare leveringsidentificator. Namen zijn meestal niet uniek, adressen niet per se, en telefoonnummers worden gedeeld. Zelfs waarden die er vandaag uniek uitzien, zijn dat misschien niet meer als je genoeg data hebt. Vraag dus: kunnen twee hiervan ooit dezelfde waarde hebben? Als het antwoord ja is, wees dan heel voorzichtig met het gebruik ervan als unieke ID van het record.
Onveranderlijk. Deze wordt vaak gemist. Als we een retailpartner identificeren met zijn naam en de partner verandert van naam, hebben we dan een nieuwe partner? Nee. De bedrijfsentiteit bleef hetzelfde; een van haar attributen veranderde. De unieke ID van een record moet veranderingen overleven van het ding dat hij identificeert, en dat sluit namen, e-mailadressen, telefoonnummers, adressen en gebruikersnamen uit, hoe handig ze er ook uitzien als we een systeem voor het eerst bouwen.
Betekenisloos. Dit klinkt vreemd als je het voor het eerst hoort. Waarom zou ik een identificator betekenisloos willen? Omdat betekenis verandert. Stel dat iemand een leverings-ID bouwt waarin het DC, de retailpartner, de bezorgdatum en een volgnummer zitten: PHX-KEY-20261002-0042. Het ziet er slim uit. Dan verzet de ontvanger de levering naar vrijdag. Veranderen we de identificator? Zo niet, dan liegt hij tegen ons. Zo ja, dan hebben we de unieke ID van de levering veranderd omdat een van haar attributen veranderde, en elk systeem dat de oude ID opsloeg is haar net kwijtgeraakt. De identificator probeerde twee taken te doen: de levering identificeren en haar beschrijven. Ik laat liever de attributen haar beschrijven en de identificator één saaie taak doen: haar identificeren. Saaie identificatoren zijn goede identificatoren.
Nooit persoonsgegevens. Deze is belangrijk genoeg om apart te houden. Gebruik geen persoonsgegevens als identificator alleen omdat ze er uniek uitzien. Bij Steve Trucking is het verleidelijk een ontvanger te herkennen aan zijn telefoonnummer. Maar een sleutel wordt overal heen gekopieerd waar systemen records moeten verbinden: integraties, exports, logs, statusbestanden terug naar de retailpartners, het datawarehouse, testdata. Maak een telefoonnummer de sleutel, en je hebt de persoonsgegevens van een ontvanger door de hele architectuur verspreid.
Een sleutel moet er ook voor elk record zijn: nooit null of leeg. Als sommige mensen een waarde niet willen geven, of dat niet zouden moeten hoeven, kan die waarde niet de sleutel zijn. Daarom geven systemen hun eigen interne identificatoren uit, en worden persoonsgegevens, als je ze al nodig hebt, een beschermd attribuut.
Mijn regel is dus: uniek, onveranderlijk, betekenisloos, nooit persoonsgegevens.
Natuurlijke sleutels en surrogaatsleutels
Section titled “Natuurlijke sleutels en surrogaatsleutels ”Databasemensen hebben namen voor een deel hiervan. Een natuurlijke sleutel bestaat al in de bedrijfsdata: het VIN van een vrachtwagen is een goed voorbeeld. Onze applicatie heeft hem niet bedacht, en hij heeft al betekenis. Een surrogaatsleutel wordt speciaal gemaakt om het record te identificeren; hij beschrijft niets, hij identificeert alleen.
In de meeste architecturen heb ik liever een surrogaatsleutel als intern record-ID en houd ik de belangrijke natuurlijke identificatoren als attributen. Dat maakt natuurlijke identificatoren niet slecht; ze zijn vaak buitengewoon belangrijk. Ik maak ze alleen niet automatisch de unieke ID van het record. Vraag wat er gebeurt als de waarde gecorrigeerd, anders opgemaakt, vervangen of hergebruikt wordt, ontbreekt, of uit meer dan één bronsysteem komt. Daar wordt een simpel ogende beslissing een architectuurbeslissing.
Eén ding kan meerdere nuttige identificatoren hebben
Section titled “Eén ding kan meerdere nuttige identificatoren hebben ”Het interne record-ID is niet per se de identificator die elk ander systeem gebruikt. Steve Trucking identificeert een levering intern misschien met een gegenereerde ID. Elke retailpartner kent dezelfde levering onder een eigen ordernummer: Keystone in zijn CSV-vrachtlijst, Redrock in zijn API, Brightwave in zijn EDI-berichten. En de acht jaar historie in RouteDesk, de oude planningstool, gebruiken de eigen leverings-ID’s van RouteDesk.
Die identificatoren doen ertoe. We moeten ze bewaren en correct koppelen, omdat een statusupdate naar elke partner terug moet onder zijn nummer. Maar ze hoeven niet allemaal de unieke ID van de levering te worden. “Wat is de ID?” kan meer dan één antwoord hebben, en de architect moet weten welke ID in welke context gezaghebbend is. We komen hierop terug bij stamgegevens en integratie.
Relaties hangen af van unieke ID’s
Section titled “Relaties hangen af van unieke ID’s ”Ga nu terug naar de lijnen die we tekenden. Een vrachtlijst bevat leveringen. Een ontvanger ontvangt leveringen. Een ploeg heeft ploegtoewijzingen. Die relaties werken alleen omdat we de dingen aan beide uiteinden betrouwbaar kunnen identificeren.
Hier gaat het bij Steve Trucking mis. Een retailpartner wijzigt zijn vrachtlijst op de dag zelf: een order geannuleerd, een artikel omgewisseld, een nieuw adres. Als we de gewijzigde regel niet kunnen koppelen aan de levering die we al hebben, via het ordernummer van de partner, maken we een tweede levering aan voor dezelfde koelkast, en staat er misschien twee keer een ploeg voor de deur. Blokken, attributen, sleutels en relaties zijn geen losse ideeën. Ze zijn allemaal onderdeel van hetzelfde model.
Op dit punt denk je misschien: “Salesforce geeft elk record een ID.” Klopt, en daar komen we nog. Als de data in Salesforce staat, krijgt elk record een door Salesforce gegenereerde ID. Die is cryptisch en slecht leesbaar, dus meestal tonen we ook een ID-veld dat mensen kunnen gebruiken, zoals een leveringsnummer D-000184227, een veld van het type Auto Number. Mensen denken vaak dat dat nummer de ID van het record is, maar dat is niet zo: de Salesforce-ID zit er nog steeds onder. Een extern systeem of een database, Oracle of SQL Server, heeft ook eigen unieke ID’s. Maar de architectuur kan uiteindelijk Salesforce omvatten, het financiële ERP, Snowflake, Data 360, de systemen van de partners en systemen die nog niet bestaan. Het logische model beschrijft de bedrijfsdata zonder elke beslissing van één technologie te laten afhangen. Hoe Salesforce het fysiek implementeert, is een latere stap.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”Als ik een conceptueel model omzet in een logisch model, beslis ik:
- Welke attributen elke entiteit echt beschrijven.
- Hoe elke entiteit uniek wordt geïdentificeerd, en of die identificator stabiel genoeg is om haar unieke ID te zijn.
- Welke bedrijfsidentificatoren (ordernummers van partners, oude ID’s) bewaard en gekoppeld moeten worden.
- Of gevoelige informatie als sleutel wordt gebruikt.
- Of relaties entiteiten verbinden via betrouwbare unieke ID’s.
We hebben nu entiteiten, relaties, attributen en unieke ID’s: het begin van een echt logisch datamodel. Maar er is nog een probleem. Het is heel makkelijk volkomen geldige data op de verkeerde plek te zetten. Daar komt normalisatie om de hoek kijken.
Verder lezen
Section titled “Verder lezen ”- Custom Field Types (opens in a new tab), Salesforce Help (Engels, gecontroleerd op 2026-10-09): Auto Number geeft elk record een uniek nummer met een weergaveformaat, zoals een voorvoegsel en voorloopnullen; het is niet de Salesforce-ID van het record. Zie ook Auto-Number Fields Are Not Always Sequential (opens in a new tab) (Engels, gecontroleerd op 2026-10-09).