Dai requisiti al data model

Il punto di partenza di ogni soluzione Power Platform non è la tabella, ma il requisito funzionale. Prima di aprire il designer conviene tradurre i processi di business in nomi (entità candidate), attributi (le informazioni da tracciare) e verbi/relazioni (come le entità interagiscono). In Microsoft Dataverse queste tre dimensioni diventano rispettivamente table, column e relationship (la vecchia terminologia entity/field/relationship resta valida negli esami e nell’SDK).

L’analisi produce un conceptual data model che, solo in un secondo momento, si mappa sui costrutti fisici di Dataverse. Per ogni entità candidata la domanda chiave è: esiste già una tabella che copre questo concetto?

Tabelle standard, custom e riuso

Dataverse fornisce standard tables (Account, Contact, Activity, ecc.) ricche di logica, relazioni e integrazioni già pronte (Dynamics 365, Customer Insights). La regola di design è:

  • Riusa una standard table quando il concetto è generico e ben modellato (es. un cliente → Account/Contact). Estendila con column custom invece di ricrearla.
  • Crea una custom table solo quando il concetto è specifico del dominio e non esiste un equivalente adeguato.
  • Valuta le virtual tables quando i dati risiedono in un sistema esterno e non devono essere copiati in Dataverse.
  • Considera le elastic tables (backend NoSQL) per scenari ad altissimo volume, scritture massive o schema variabile, dove le tabelle relazionali standard non scalano bene.

Il riuso riduce manutenzione, sfrutta sicurezza e viste esistenti e migliora l’interoperabilità.

Attributi e relazioni: le scelte che contano

La scelta del data type delle column è una decisione architetturale, non estetica. Due errori ricorrenti riguardano choice vs lookup:

  • Usa una choice (già “option set”, locale o global choice riutilizzabile) per un insieme fisso e piccolo di valori gestiti dallo sviluppatore (es. priorità Alta/Media/Bassa).
  • Usa una lookup quando il valore è una riga di un’altra tabella che può crescere, avere attributi propri o essere gestita dagli utenti (es. Città, Fornitore). La lookup crea automaticamente una relazione 1:N.

Sul fronte relazioni: una lookup modella un legame N:1 / 1:N; una relazione N:N (native many-to-many) va usata solo per associazioni pure senza dati aggiuntivi — se la relazione ha attributi propri (es. data, quantità), serve una intersect table custom con due lookup. Le alternate key sono utili per integrazioni e upsert basati su chiavi di business.

Normalizzazione vs denormalizzazione

Dataverse è relazionale: normalizza per evitare duplicazione e anomalie. Tuttavia una denormalizzazione mirata è legittima quando serve performance — ad esempio rollup column e calculated column per aggregare dati correlati senza query costose lato client, o la duplicazione controllata di un valore per ridurre join in scenari read-intensive.

La solution come contenitore fin dal design

Un errore diffuso è modellare le tabelle nel default environment/default solution. Dal primo momento di design va definita una unmanaged solution con un publisher dedicato e un customization prefix proprio (es. new_ sostituito da un prefisso aziendale). Tutti gli oggetti (tables, columns, choices, relationships) nascono così tracciati e trasportabili attraverso il ciclo ALM dev → test → prod come managed solution. Pensare alla solution come confine del progetto guida anche la scelta tra global e local choice e la coerenza dei nomi.

Storage e scalabilità

Dataverse fattura tre tipi di capacità: Database, File e Log. Le scelte di modeling impattano il consumo: preferisci il tipo File/Image per allegati anziché salvarli come testo, evita column ridondanti, e valuta le elastic tables per dati ad alto volume. Considera fin dal design indici, chiavi alternative e volumi attesi.

Trappole tipiche d’esame

  • Scenario: valori a lista che gli utenti devono poter aggiungere/estendere nel tempo → risposta: usa una lookup verso una tabella, non una choice (le choice richiedono un intervento dello sviluppatore/solution).
  • Scenario: una relazione many-to-many che deve tracciare data e stato dell’associazione → risposta: non una native N:N, ma una intersect table custom con due lookup e le column aggiuntive.
  • Scenario: requisito “gestire un cliente” → risposta: riusa/estendi la standard table Account/Contact, non creare una custom table duplicata (evita l’over-engineering).
  • Scenario: oggetti creati per errore nella default solution e non trasportabili verso test/prod → risposta: lavora sempre in una unmanaged solution con publisher e prefix dedicati, esporta come managed.
  • Scenario: milioni di righe con scritture frequenti e schema semplice → risposta: valuta una elastic table invece di una standard table relazionale per la scalabilità.