Fondamenti del data model in Dataverse

Come Solution Architect il tuo compito non è “creare tabelle”, ma tradurre requisiti di business in un modello dati che regga nel tempo. Dataverse ti dà relazioni gestite, sicurezza granulare, logica server-side e integrazione nativa con l’ecosistema Power Platform: partire da qui riduce il codice custom, ma ti obbliga a ragionare fin dall’inizio su normalizzazione, performance e modello di sicurezza, che in Dataverse sono strettamente intrecciati.

Tabelle, colonne e scelte di tipizzazione

Distingui subito le standard/custom tables (persistite in Dataverse) dalle activity tables (pattern per interazioni temporali). Per le colonne, la decisione ricorrente è choice vs lookup:

  • Choice (option set): valori statici, poco numerosi, senza metadati aggiuntivi (es. priorità, stato). Sono globali o locali, veloci da filtrare, ma rigidi: aggiungere valori è un’attività di governance, non self-service.
  • Lookup (relazione): quando i valori sono dati gestiti dall’utente, crescono nel tempo o portano attributi propri (es. “Fornitore”, “Categoria prodotto”). Un lookup è una relazione N:1 mascherata: abilita reporting, sicurezza per record e riuso.

La trappola tipica è modellare come choice ciò che è di fatto un’entità (con proprietario, descrizione, storicità): quando serviranno metadati sarai costretto a un refactoring costoso.

Relazioni: 1:N, N:1 e il rischio delle many-to-many

Le relazioni 1:N/N:1 sono la spina dorsale del modello e supportano cascade behavior configurabili (assign, delete, share, reparent). Le N:N native sono comode ma hanno un costo architetturale: non possono portare attributi propri, non partecipano al modello di sicurezza in modo granulare e complicano query e rollup.

Raccomandazione da architetto: quando la relazione molti-a-molti deve trasportare dati (data di associazione, quantità, ruolo) o richiede sicurezza per record, introduci una manual intersect / junction table (entità intermedia con due lookup). Ottieni controllo su permessi, audit e reporting, a fronte di poco lavoro aggiuntivo.

Alternate keys e integrità

Le alternate keys definiscono unicità su una o più colonne alternative alla GUID di sistema. Sono essenziali per le integrazioni: consentono upsert idempotenti basati su chiavi esterne (es. codice ERP) senza dover prima leggere il GUID. Valuta l’impatto su performance in scrittura (indice mantenuto) e i limiti di lunghezza sui campi componenti.

Virtual ed elastic tables

  • Virtual tables: i dati restano nel sistema sorgente (SQL, API) e Dataverse li espone senza copiarli. Ideali quando la source of truth deve rimanere esterna per compliance o per il costo di una migrazione. Limiti: funzionalità ridotte (audit, alcune business rule, offline) e dipendenza dalle performance del provider.
  • Elastic tables (su Cosmos DB): pensate per volumi molto alti, schema variabile e ingest ad alta frequenza (IoT, telemetria). Rinunci ad alcune capacità relazionali in cambio di scalabilità orizzontale.

Dataverse vs storage esterno secondo il Well-Architected Framework

Applica i pilastri dell’Azure Well-Architected Framework alla scelta:

  • Reliability / Operational Excellence: Dataverse offre ALM maturo (solution, managed environments). Dati fuori significano più moving parts da governare.
  • Security: Dataverse porta RBAC, security roles, column-level security e integrazione con Microsoft Entra ID e Microsoft Purview per classificazione e DLP. Uno storage esterno richiede di ricostruire questi controlli.
  • Performance Efficiency: milioni di righe transazionali con logica di sicurezza per record → Dataverse; blob di grandi dimensioni, log immutabili o analytics massivi → Azure Data Lake / Blob con Synapse Link in sola lettura.
  • Cost Optimization: la capacity Dataverse è preziosa. File e dataset di puro reporting stanno meglio esternalizzati e collegati via virtual table o Synapse Link.

La regola pratica: tieni in Dataverse ciò che ha bisogno di sicurezza per record, workflow e collaborazione; esternalizza ciò che è volume, archivio o analytics.

Trappole tipiche d’esame

  • Requisito: relazione molti-a-molti con data di validità e permessi diversi per riga → NON usare N:N nativa; introduci una junction table con due lookup per avere attributi e sicurezza per record.
  • Requisito: dashboard che aggrega valori su migliaia di record correlati con più livelli → i rollup fields a cascata ricalcolano in batch asincrono e degradano; preferisci aggregazioni via Synapse Link + Power BI o calcolo applicativo mirato.
  • Requisito: i dati anagrafici devono restare nel sistema legacy per compliance → virtual table, non migrazione; la source of truth resta esterna e Dataverse la espone in lettura/scrittura via provider.
  • Requisito: upsert idempotente da un ERP che invia un codice univoco → definisci una alternate key su quel codice, evitando lookup preventive del GUID.
  • Requisito: milioni di eventi di telemetria ad alta frequenza → elastic table, non tabella standard con rollup, per scalabilità e schema flessibile.