Entity Guidelines beschrijven de richtlijnen voor het ontwerpen van tabellen, relaties en kolommen binnen Dataverse.
Een goed datamodel vormt de basis van iedere succesvolle Power Platform-oplossing.
A bad data model becomes a problem everywhere. A good data model becomes invisible.
Deze richtlijnen ondersteunen teams bij:
Het doel is om een datamodel te realiseren dat:
Binnen Dataverse gelden de volgende uitgangspunten.
Ontwerp het datamodel vanuit het bedrijfsproces.
Gebruik standaard Dataverse-tabellen wanneer deze voldoen aan de behoefte.
Houd het datamodel zo eenvoudig mogelijk.
Sla dezelfde informatie slechts één keer op.
Voorkom datakwaliteitsproblemen door een goed ontwerp.
Tabellen vormen de kern van het datamodel.
Iedere tabel moet een duidelijk functioneel doel hebben.
✅ Iedere tabel ondersteunt een businessconcept
✅ Gebruik standaardtabellen waar mogelijk
✅ Definieer eigenaarschap
✅ Vermijd overlap met bestaande tabellen
🚫 Tabellen zonder duidelijke businesswaarde
🚫 Technische tabellen voor functionele gegevens
🚫 Meerdere tabellen voor hetzelfde concept
Gebruik een begrijpelijke naam voor eindgebruikers.
Account
Subscription
Project
Service Request
✅ Enkelvoud
✅ Begrijpelijk
✅ Functioneel
<publisher>_<name>
brenke_project
brenke_subscription
brenke_registration
✅ Publisher prefix verplicht
✅ Beschrijvend
✅ Geen afkortingen zonder duidelijke betekenis
Kolommen beschrijven welke informatie wordt opgeslagen.
Iedere kolom moet een duidelijk doel hebben.
✅ Gebruik beschrijvende namen
✅ Maak verplichte velden alleen indien noodzakelijk
✅ Gebruik het juiste datatype
✅ Ondersteun rapportages en integraties
🚫 Overmatige gegevensregistratie
🚫 Ongebruikte velden
🚫 Onduidelijke betekenis
Gebruik het datatype dat het beste aansluit bij de gegevens.
| Type | Toepassing |
|---|---|
| Text | Namen, omschrijvingen |
| Choice | Statussen, categorieën |
| Number | Hoeveelheden |
| Currency | Bedragen |
| Date | Datums |
| Lookup | Relaties |
| Yes/No | Booleans |
Relaties bepalen hoe gegevens met elkaar verbonden zijn.
Een goede relatie ondersteunt:
Eén record is gekoppeld aan meerdere gerelateerde records.
Voorbeeld
Account
↓
Contact
Een record verwijst naar een hoofdrecord via een lookup.
Voorbeeld
Contact
↓
Account
Meerdere records kunnen aan meerdere andere records gekoppeld worden.
Voorbeeld
Contact
↔
Competentie
✅ Eenvoudige many-to-many relaties
✅ Geen aanvullende gegevens nodig op de relatie
Contact ↔ Marketinglijst
Gebruiker ↔ Competentie
Project ↔ Documentcategorie
Wanneer de relatie zelf aanvullende gegevens bevat, verdient een expliciete tabel meestal de voorkeur boven een standaard N:N relatie.
Werknemer
↓
Dienstverband
↓
Werkgever
De tabel Dienstverband legt de relatie vast en bevat aanvullende informatie zoals:
✅ De relatie bevat eigen attributen
✅ Historie moet worden bijgehouden
✅ De relatie heeft een eigen lifecycle
✅ Rapportages zijn gebaseerd op de relatie zelf
Een relatie die eigen gegevens bevat is vaak geen relatie meer, maar een zelfstandig businessobject.
In dat geval heeft een expliciete tabel vrijwel altijd de voorkeur boven een standaard N:N relatie.
✅ Gebruik relaties om samenhang te modelleren
✅ Gebruik lookupvelden voor eigenaarschap en afhankelijkheden
✅ Definieer duidelijke parent-child structuren
🚫 Overmatig gebruik van N:N relaties
🚫 Relaties zonder businessdoel
🚫 Complexe afhankelijkheidsstructuren
Met Field Mapping kunnen waarden automatisch worden overgenomen wanneer een nieuw child record wordt aangemaakt.
Account
↓
Nieuw Contact
Account Naam
↓
Contact > Account Naam
✅ Standaardwaarden overnemen
✅ Klantinformatie vooraf invullen
✅ Administratieve gegevens overnemen
🚫 Businesslogica implementeren
🚫 Synchronisatie tussen records
🚫 Automatische updates na wijzigingen
Mapping werkt uitsluitend:
✅ tijdens het aanmaken van een record
✅ wanneer het record via de relatie wordt aangemaakt
Mapping werkt niet:
❌ bij latere wijzigingen
❌ als synchronisatiemechanisme
❌ voor bestaande records
Cascading bepaalt welk gedrag automatisch wordt uitgevoerd op gerelateerde records.
Voor iedere relatie kan gedrag worden ingesteld voor:
Actie wordt uitgevoerd op alle gerelateerde records.
Actie wordt uitsluitend uitgevoerd op actieve records.
Actie wordt alleen uitgevoerd op records van dezelfde eigenaar.
Actie wordt geblokkeerd zolang gerelateerde records bestaan.
Er gebeurt niets met gerelateerde records.
Bij voorkeur:
Restrict
Voorkomt onbedoeld dataverlies.
Vaak geschikt:
Cascade User-Owned
of
Cascade All
Afhankelijk van het proces.
Alleen toepassen wanneer de securitybehoefte hierom vraagt.
Onjuiste configuratie kan leiden tot:
Een verkeerd ingestelde:
Delete = Cascade All
kan honderden of duizenden records verwijderen.
Iedere tabel moet een eigenaar hebben.
Denk hierbij aan:
🚫 Geen eigenaar
🚫 Onduidelijke verantwoordelijkheden
Datakwaliteit wordt grotendeels bepaald door het datamodel.
✅ Gebruik verplichte velden waar nodig
✅ Gebruik Duplicate Detection
✅ Gebruik consistente Choices
✅ Leg eigenaarschap vast
✅ Definieer een Source of Truth
🚫 Dubbele gegevens
🚫 Meerdere bronnen voor dezelfde informatie
🚫 Onduidelijke definities
✔ Ontwerp vanuit processen
✔ Gebruik standaardtabellen waar mogelijk
✔ Definieer eigenaarschap
✔ Houd relaties eenvoudig
✔ Pas Naming Conventions toe
✔ Analyseer cascading vooraf
✔ Overweeg een intersect tabel wanneer een relatie eigen gegevens bevat
✘ Dataduplicatie
✘ Overmatig maatwerk
✘ Onduidelijke relaties
✘ Tabellen zonder businesswaarde
✘ Cascade All zonder impactanalyse
✘ Te complexe datamodellen
Een goed ontworpen datamodel:
👉 Tabellen, kolommen en relaties vormen de fundering van iedere Power Platform-oplossing. Tijd investeren in een goed ontwerp voorkomt veel problemen tijdens ontwikkeling, beheer en toekomstige uitbreidingen.