Dataverse: Relazioni e Integrità

Introduzione alle relazioni in Dataverse

In Microsoft Dataverse, le relazioni tra tabelle definiscono come i record interagiscono tra loro. Ogni applicazione basata su Dataverse — come una Power App o una Power Automate Flow — si fonda su un modello dati relazionale che consente di mantenere coerenza e integrità tra le entità.

Le relazioni possono essere di tre tipi principali:

• Uno-a-molti (1:N): un record nella tabella primaria è associato a più record nella tabella correlata.
• Molti-a-uno (N:1): molti record di una tabella fanno riferimento a un singolo record in un’altra tabella.
• Molti-a-molti (N:N): ogni record in una tabella può essere associato a più record in un’altra tabella e viceversa.

Quando si progetta un modello dati in Dataverse, è importante scegliere il tipo di relazione corretto per rappresentare il comportamento reale dei dati e le dipendenze logiche tra gli oggetti del dominio aziendale.

Relazioni 1:N e N:1

Una relazione 1:N (uno-a-molti) in Dataverse viene configurata definendo una tabella principale (il lato “uno”) e una tabella correlata (il lato “molti”). Ad esempio, un record “Account” può essere collegato a più record “Contatti”.

La relazione inversa, N:1, rappresenta lo stesso legame ma vista dal lato opposto: ogni contatto appartiene a un solo account. In pratica, Dataverse implementa entrambe le direzioni all’interno della stessa relazione, consentendo un accesso bidirezionale ai dati.

Durante la creazione della relazione, tramite il Power Apps Maker Portal, l’amministratore definisce il comportamento e le regole di integrità che determinano cosa accade quando vengono aggiornati o eliminati i record correlati.

Le relazioni 1:N sono alla base di molte logiche aziendali: permettono di strutturare gerarchie, assegnazioni e dipendenze tra tabelle mantenendo la coerenza del dato.

Relazioni N:N e tabelle di intersezione

Le relazioni N:N (molti-a-molti) sono gestite in Dataverse tramite tabelle di intersezione (o tabelle di collegamento) create automaticamente dal sistema. Queste tabelle contengono le chiavi primarie delle due tabelle correlate, stabilendo così una connessione bidirezionale.

Ad esempio, la relazione tra la tabella “Utenti” e la tabella “Progetti” può essere molti-a-molti, poiché ogni utente può partecipare a più progetti e ogni progetto può avere più utenti assegnati. In Dataverse, questa relazione viene rappresentata tramite una tabella nascosta che associa i record delle due entità.

Le relazioni N:N sono utili per rappresentare scenari complessi senza duplicare dati, migliorando la normalizzazione e la manutenibilità del database.

Regole di integrità e comportamenti di cascading

Ogni relazione in Dataverse può essere configurata per definire il comportamento dei record correlati in risposta a eventi specifici, come eliminazione, assegnazione, condivisione o riassegnazione di un record principale. Queste configurazioni garantiscono l’integrità referenziale del modello dati.

I comportamenti disponibili sono generalmente tre:

• Parental: le modifiche al record principale (ad esempio, eliminazione o assegnazione) si propagano automaticamente ai record correlati.
• Referential: le modifiche al record principale non influenzano i record correlati; la relazione è logica, non vincolante.
• Custom: permette di definire un comportamento personalizzato per ciascun evento (Delete, Assign, Share, Unshare, Reparent).

Un esempio pratico è la cancellazione in cascata: se un account viene eliminato, tutti i contatti associati possono essere eliminati automaticamente (Parental) oppure mantenuti indipendenti (Referential).

La scelta del tipo di comportamento dipende dal contesto aziendale e dalla logica applicativa. In un sistema CRM, ad esempio, è consigliabile mantenere un comportamento referenziale per evitare la perdita involontaria di dati storici.

Progettazione e buone pratiche

Progettare relazioni corrette è uno dei pilastri di un modello Dataverse efficiente. Alcune buone pratiche includono:

• Usare relazioni 1:N per rappresentare gerarchie naturali (ad esempio, Azienda → Contatti).
• Limitare l’uso di relazioni N:N solo quando necessario, poiché aumentano la complessità delle query.
• Definire il comportamento di integrità in base ai processi aziendali reali e alle policy di gestione dati.
• Documentare ogni relazione, specificando la direzione e il tipo di comportamento impostato.
• Verificare le performance delle query che coinvolgono molte relazioni, specialmente nei report Power BI con DirectQuery.

Durante la configurazione nel Maker Portal, puoi visualizzare e modificare tutte le relazioni nella sezione “Relazioni” di ciascuna tabella, con la possibilità di gestire anche le regole di cascading.

Relazioni e sicurezza dei dati

Le relazioni tra tabelle in Dataverse interagiscono anche con il modello di sicurezza. I record correlati ereditano o meno i permessi a seconda della configurazione dei ruoli di sicurezza e del comportamento impostato.

Ad esempio, in una relazione di tipo Parental, quando un record viene condiviso, anche i record correlati possono essere condivisi automaticamente con lo stesso utente o team. Questo approccio semplifica la gestione dell’accesso ai dati in scenari complessi.

Nei casi in cui è richiesta una maggiore granularità, è possibile applicare controlli a livello di colonna o di riga (Row-Level Security), integrando le relazioni con le policy di sicurezza Dataverse.

Per approfondire, consulta la guida Microsoft su Microsoft Dataverse: Introduzione alla sicurezza e ai dati.