Uso degli elementi costitutivi di base di Microsoft Dataverse

Completato

Nell'ultima unità sono stati introdotti i concetti di dati comuni usati da Common Data Service. Ora verrà esaminato più in dettaglio ciascuno di questi elementi costitutivi e verrà spiegato come configurarli.

Entità

Le entità sono usate per modellare e gestire dati aziendali. Quando si lavora con un'app basata su modello Dynamics 365, è possibile usare entità standard, entità personalizzate o entrambe. Per impostazione predefinita, Microsoft Dataverse fornisce entità standard. Queste sono concepite secondo le procedure consigliate per acquisire i concetti e gli scenari più comuni di un'organizzazione. Se l'organizzazione presenta requisiti aziendali univoci che non rientrano in questi scenari comuni, è possibile creare un'entità personalizzata. La schermata seguente mostra le entità attualmente esistenti nel sistema e fornisce l'opzione per aggiungere una nuova entità personalizzata.

Visualizzazione delle entità in Common Data Model

Verranno illustrate le entità nel contesto dell'organizzazione di esempio, Contoso Research. Contoso Research usa Dynamics 365 per mantenere un elenco di persone interessate a partecipare a un gruppo di discussione o che vi hanno partecipato in passato. Archivia i nomi e le informazioni di contatto di queste persone in un'entità chiamata Contatto, che è un'entità predefinita; poiché la maggior parte delle organizzazioni deve tenere traccia di un elenco di contatti, si tratta di un'entità standard nel Common Data Model.

Tuttavia, Contoso Research ha anche l'esigenza di registrare alcune operazioni univoche in Dynamics 365. Come requisito aziendale, deve registrare ogni gruppo di discussione che organizza e facilita. Poiché Gruppo di discussione non è un'entità standard in Common Data Model, si potrebbe creare una nuova entità personalizzata per registrare la data, l'ora, i risultati, la posizione o qualsiasi altra informazione pertinente del gruppo di discussione.

Record

Un record è semplicemente un'istanza di un'entità.

Ad esempio, una nuova persona di nome Joanna Meyers ha appena chiesto a Contoso Research informazioni sulla partecipazione ai prossimi gruppi di discussione o sondaggi. Un utente Dynamics 365 potrebbe creare un nuovo record Contatto chiamato Joanna Meyers. In questo record individuale, l'utente può acquisire dati pertinenti su Joanna (come le sue informazioni di contatto) per associarla a opportunità di ricerca imminenti.

Campi

Si è visto in precedenza come registrare i dati pertinenti su Joanna Meyers nel suo record Contatto. I campi rappresentano il modo in cui si acquisiscono e visualizzano tali dati.

Consentono di archiviare informazioni discrete all'interno di un record in un'entità. Sono simili alle colonne di Excel. I campi presentano tipi, quindi è possibile archiviare dati di un certo tipo in un campo che corrisponde a quel tipo di dati. Ad esempio, se si ha una soluzione che richiede una data, la data verrà archiviata in un campo di tipo Data. Analogamente, per archiviare un numero si usa un campo di tipo Numero.

Dal momento che Contatto è un'entità standard in Common Data Model, viene fornito con un set standard di campi (o attributi) che includono, ad esempio, Nome, Cognome, Data di nascita e Indirizzo e-mail. Un rappresentante di Contoso Research che volesse registrare tutti questi attributi su Joanna Meyers avrebbe probabilmente bisogno anche di alcune informazioni aggiuntive specifiche per l'organizzazione. In questo caso, sarebbe necessario aggiungere un campo personalizzato all'entità Contatto per integrare i campi standard inclusi in Common Data Model.

Ad esempio, si supponga che Contoso Research abbia la necessità di registrare il tipo di attività di ricerca a cui un contatto potrebbe essere interessato. Si potrebbe creare un nuovo campo personalizzato con il nome visualizzato di Interessato a e il tipo di campo Set di opzioni a selezione multipla. Nel set di opzioni si potrebbero inserire le opzioni personalizzate riportate di seguito tra cui un utente può scegliere:

  • Gruppi di discussione

  • Sondaggi online

  • Sondaggi telefonici

  • Studi in presenza a lungo termine

  • Studi virtuali a lungo termine

Usando il tipo di campo a selezione multipla, l'utente può selezionare i tipi di attività di ricerca a cui Joanna è interessata in modo da poterla contattare non appena si presentano opportunità specifiche.

Relazioni

Le relazioni di entità definiscono il modo in cui i record sono correlati tra loro nel database. Esistono due tipi di relazioni di entità:

Tipo relazione Descrizione
1:N (uno-a-molti) Una relazione di entità in cui un record di entità per l'Entità primaria può essere associato a molti altri record Entità correlata per effetto di un campo di ricerca sull'entità correlata.
N:N (molti-a-molti) Una relazione di entità che dipende da un'Entità di relazione speciale, a volte denominata entità intersecata, affinché molti record di un'entità possano essere correlati a molti record di un'altra entità. Quando si visualizzano i record di una delle tabelle in una relazione N:N, è possibile visualizzare un elenco di tutti i record correlati dell'altra tabella.

Le relazioni 1:N esistono effettivamente tra le entità e fanno riferimento a ogni entità come entità primaria/corrente o entità correlata. L'entità correlata, a volte chiamata entità figlio, ha un campo di ricerca che consente di archiviare un riferimento a un record dall'entità primaria, a volte denominata anche entità padre.

Al livello più semplice, l'aggiunta di un campo di ricerca a un'entità crea una nuova relazione 1:N (uno a molti) tra le due entità e consente di inserire quel campo di ricerca in un modulo. Con il campo di ricerca, gli utenti possono associare più record figlio di tale entità a un singolo record di entità padre.

Oltre a definire semplicemente il modo in cui i record possono essere correlati ad altri record, le relazioni di entità 1:N forniscono anche i dati per rispondere alle domande seguenti:

  • Quando si elimina un record, è necessario eliminare anche tutti i record correlati?

  • Quando si assegna un record, è necessario assegnare anche tutti i record correlati al nuovo proprietario?

  • Come si può ottimizzare il processo di inserimento dei dati quando si crea un nuovo record correlato nel contesto di un record esistente?

  • In che modo le persone che visualizzano un record possono visualizzare i record associati?

Si discuterà dell'organizzazione di esempio fittizia Contoso Research. In passato abbiamo usato due entità: Contatto (un'entità standard) e Gruppo di discussione (un'entità personalizzata). Nella vita reale, questi due concetti sono correlati. Un contatto può partecipare a più gruppi di discussione e un gruppo di discussione di solito ha più contatti che partecipano. In Dynamics 365, verrebbe creata una relazione N:N (molti a molti) tra l'entità Contatto e l'entità Gruppo di discussione. L'entità di relazione (o entità intersecata) potrebbe chiamarsi Partecipante al gruppo di discussione. Dal punto di vista del record Contatto, si potrebbero registrare i gruppi di discussione a cui ha partecipato (o parteciperà) un singolo partecipante. Dal record Gruppo di discussione si potrebbero registrare i contatti che stanno partecipando.

Quando si configura una nuova app basata su modello, usare sempre entità e campi standard quando possibile. È possibile rinominare un'entità per renderla più comprensibile nel contesto della soluzione. Esaminare sempre l'elenco delle entità standard e, prima di creare una nuova entità standard, verificare che non siano presenti entità standard in grado di soddisfare le esigenze.

L'unità successiva spiega come visualizzare questi concetti nell'interfaccia utente.