Dataverse-tabel

Wat is een Dataverse-tabel?

Een Dataverse-tabel beschrijft een soort bedrijfsobject waarvan records worden opgeslagen of weergegeven. Voorbeelden zijn klant, dossier, inspectie en factuur.

De tabel bepaalt meer dan een verzameling velden. Ze omvat kolommen, relaties, ownership, privileges, forms, views, business rules en andere metadata die apps en automatiseringen gebruiken.

Iedere tabel heeft een unieke logische naam en iedere record een GUID als primaire sleutel. Een primary name-kolom levert de herkenbare tekst die gebruikers in lookups zien.

Standaard- en custom tables

Dataverse bevat standaardtabellen zoals Account en Contact. Dynamics 365-apps voegen verdere tabellen en gedrag toe. Hergebruik kan integratie en bekende functionaliteit opleveren.

Een custom table wordt voor een eigen domein gemaakt en krijgt de publisherprefix van de solution. Kies een enkelvoudige, stabiele bedrijfsnaam in plaats van een tijdelijke scherm- of projectnaam.

Controleer vóór creatie of een bestaande tabel werkelijk dezelfde betekenis en lifecycle heeft. Een technisch vergelijkbare tabel hergebruiken voor een ander begrip maakt relaties en rapportage verwarrend.

Ownership

Een user- of team-owned table heeft per record een eigenaar. Dataverse kan toegang afleiden uit security roles, business units, teams en delen.

Een organization-owned table heeft geen eigenaar per record. Toegang wordt op organisatieniveau toegekend en past vaak bij referentie- of configuratiegegevens.

Ownership is een fundamentele ontwerpkeuze en kan niet zomaar na ingebruikname worden omgezet. Bepaal vroeg of records verschillende vertrouwelijkheidsgrenzen hebben.

Een klant-dossiermodel

Een organisatie maakt tabellen Klant, Dossier, Document en Beoordeling. Eén klant kan meerdere dossiers hebben; een dossier meerdere documenten en beoordelingen.

Dossier is user-owned omdat teams alleen hun eigen werkgebied mogen zien. Een tabel Dossiertype is organization-owned omdat dezelfde referentiewaarden voor iedereen gelden.

Forms en views gebruiken dezelfde metadata. Een model-driven app kan daardoor een dossierformulier, gerelateerde documenten en views per status aanbieden zonder een afzonderlijke datalaag te bouwen.

Sleutels en duplicaten

De GUID identificeert een record intern. Voor integratie kan een alternate key één of meer kolommen als unieke bedrijfssleutel vastleggen, bijvoorbeeld een extern klantnummer.

Een alternate key helpt bij upsert en voorkomt dubbele sleutelwaarden. Hij vervangt geen bredere duplicate detection wanneer gelijkheid uit meerdere onzekere kenmerken moet worden afgeleid.

Gebruik veranderlijke gegevens zoals e-mailadres voorzichtig als sleutel. Een stabiele bron-ID is meestal geschikter.

Bijzondere tabeltypes

Activity tables ondersteunen tijdlijn- en activiteitsgedrag voor zaken zoals afspraken en taken. Elastic tables zijn gericht op bepaalde scenario's met groot volume en hebben andere mogelijkheden dan standaardtabellen.

Virtual tables tonen externe data als Dataverse-records zonder de gegevens standaard te kopiëren. Beschikbare bewerkingen hangen af van provider en bron.

Kies een type op basis van functionele en operationele eisen. Niet ieder Dataverse-onderdeel ondersteunt ieder tabeltype op dezelfde manier.

Beveiliging en auditing

Security roles geven privileges per tabel en toegangsniveau. Kolombeveiliging kan gevoelige velden verder afschermen. Formulieren verbergen is geen vervanging voor serverbeveiliging.

Auditing kan wijzigingen aan tabellen en geselecteerde kolommen registreren. Schakel het doelgericht in, want auditdata vraagt capaciteit en bewaarbeheer.

Leg bewaartermijnen, verwijderregels en eigenaarschap vast. Een tabel blijft anders groeien nadat de oorspronkelijke app al verdwenen is.

Ontwerp en ALM

Plaats custom tables in een solution en beheer schemawijzigingen via development, test en productie. Een kolom verwijderen of datatype wijzigen kan data en afhankelijke componenten raken.

Documenteer betekenis, bron, eigenaar en relaties. Test security met gewone gebruikers en valideer integraties bij iedere schemawijziging.

Een goed tabelmodel weerspiegelt duurzame bedrijfsbegrippen. Forms en apps mogen veranderen zonder dat dezelfde informatie telkens in een nieuw dataschema moet worden ondergebracht.