Relaties in Dataverse
Een goed datamodel is het fundament van elke succesvolle Dataverse-oplossing. De manier waarop je relaties tussen tabellen opzet, bepaalt hoe je data kunt bevragen, weergeven en beveiligen. Dataverse ondersteunt drie typen relaties: een-op-veel (1:N), veel-op-veel (N:N) en polymorfisch. In dit artikel leggen we elk type uit, laten we zien wanneer je welk type gebruikt en delen we best practices uit de praktijk.
Waarom relaties belangrijk zijn
Relaties definiëren hoe tabellen met elkaar verbonden zijn. Ze bepalen welke lookup-velden beschikbaar zijn in formulieren, welke subgrids je kunt tonen, hoe cascading gedrag werkt bij het verwijderen of toewijzen van records en hoe je views en rapporten kunt opbouwen. Een verkeerd opgezette relatie kan leiden tot prestatieproblemen, dataverlies bij verwijdering of onmogelijkheid om de gewenste rapportages te maken.
Een-op-veel relaties
De basis van 1:N
De een-op-veel relatie is het meest gebruikte relatietype in Dataverse. Een record in de primaire tabel (de "een"-kant) kan gerelateerd zijn aan meerdere records in de gerelateerde tabel (de "veel"-kant). Technisch wordt dit geïmplementeerd door een lookup-kolom toe te voegen aan de gerelateerde tabel die verwijst naar de primaire tabel. Een voorbeeld: één account kan meerdere contactpersonen hebben. Het lookup-veld "Company Name" op de contacttabel verwijst naar de accounttabel.
Cascading gedrag
Bij het aanmaken van een 1:N-relatie configureer je het cascading gedrag: wat moet er gebeuren met gerelateerde records wanneer het primaire record wordt toegewezen, gedeeld, ontkoppeld of verwijderd? De opties variëren van Cascade All (alle gerelateerde records ondergaan dezelfde actie) tot Remove Link (alleen de koppeling wordt verbroken) tot Restrict (de actie wordt geblokkeerd als er gerelateerde records bestaan). Kies zorgvuldig, want het verkeerde cascading gedrag kan leiden tot onbedoeld dataverlies of juist tot de onmogelijkheid om records te verwijderen.
Veel-op-veel relaties
N:N relaties uitgelegd
Een veel-op-veel relatie is nodig wanneer records aan beide kanten meerdere koppelingen kunnen hebben. Een contactpersoon kan lid zijn van meerdere projecten en een project kan meerdere contactpersonen hebben. Dataverse implementeert N:N-relaties via een automatisch aangemaakte intersectietabel die de koppelrecords bevat. Je hoeft deze tussentabel niet zelf te beheren. In Power Apps worden N:N-relaties weergegeven als subgrids waarin je bestaande records kunt koppelen en ontkoppelen.
Wanneer N:N versus handmatige tussentabel
De standaard N:N-relatie heeft een beperking: je kunt geen extra attributen toevoegen aan de koppeling zelf. Als je bij de koppeling tussen een contactpersoon en een project ook de rol of startdatum wilt vastleggen, heb je een handmatige tussentabel nodig. Dit patroon (ook wel associative entity genoemd) geeft je volledige controle over de relatie-attributen en is flexibeler voor complexe scenario's.
Kies het juiste relatietype op basis van de werkelijke businessrequirements, niet op basis van wat het makkelijkst te implementeren is. Een verkeerde keuze nu leidt tot kostbare herbouw later.
Polymorfische relaties
Wat zijn polymorfische relaties?
Polymorfische relaties zijn een uniek concept in Dataverse waarbij één lookup-veld kan verwijzen naar records in meerdere tabellen. Het bekendste voorbeeld is het veld "Regarding" op de activiteitentabel: een e-mail, telefoongesprek of afspraak kan gerelateerd zijn aan een account, contactpersoon, opportunity, case of elke andere tabel die activiteiten ondersteunt. Dit is enorm krachtig maar ook complex om mee te werken.
Customer en regarding type
Dataverse kent twee ingebouwde polymorfische veldtypen: Customer (verwijst naar Account of Contact) en Regarding (verwijst naar een configureerbare set tabellen). Je kunt ook eigen polymorfische lookups maken, maar dit wordt zelden aanbevolen vanwege de complexiteit. In Dynamics 365 worden polymorfische relaties intensief gebruikt: de Customer-lookup op een opportunity laat je kiezen tussen een account en een contactpersoon zonder twee aparte velden nodig te hebben.
Best practices voor datamodellering
Op basis van onze uitgebreide ervaring bij Breathbase delen we een aantal best practices. Begin altijd met het in kaart brengen van je entiteiten en hun relaties op papier of in een ERD-tool voordat je begint met bouwen. Gebruik 1:N-relaties als standaard en switch alleen naar N:N wanneer dat daadwerkelijk nodig is. Vermijd circulaire relaties die tot verwarring en prestatieproblemen leiden. Documenteer het cascading gedrag van elke relatie en bespreek dit met de business. Test je datamodel met realistische hoeveelheden data om prestatieproblemen vroegtijdig te ontdekken. Een doordacht datamodel in Dataverse is de basis voor een schaalbare en onderhoudbare oplossing die meegroeien met de organisatie.
