Identificare i criteri di accesso per l'app

Completato

Quando si progetta un modello di dati per un database NoSQL, l'obiettivo è garantire che le operazioni sui dati siano eseguite con il minor numero possibile di richieste. A tale scopo, è necessario comprendere le relazioni tra i dati e in che modo si avrà accesso ai dati tramite l'applicazione. Questi criteri di accesso sono importanti perché, insieme alle relazioni, determineranno il modo in cui le proprietà delle varie entità vengono raggruppate e archiviate in documenti all'interno di contenitori Azure Cosmos DB for NoSQL.

In Azure Cosmos DB for NoSQL, i documenti vengono chiamati elementi e i contenitori sono spesso chiamati raccolte.

Identificare i criteri di accesso per le entità cliente

Si inizierà con le entità del cliente presenti nel database di e-commerce. Il diagramma seguente illustra tre entità e le relazioni tra di esse. Le tre entità sono Customer, CustomerAddress e CustomerPassword. L'entità Customer ha una relazione uno-a-molti con CustomerAddress. Customer ha una relazione uno-a-uno con CustomerPassword.

Diagramma che illustra il modello relazionale per le entità cliente.

In questa applicazione verranno eseguite tre operazioni sulle entità cliente:

  • Creare un cliente: quando un nuovo utente visita per la prima volta il sito di e-commerce, viene creato un nuovo cliente.
  • Aggiornare un cliente: quando un utente esistente aggiorna le informazioni del suo profilo, il record del cliente viene aggiornato.
  • Recuperare un cliente: quando un utente esistente visita il sito, accede con la propria password. Durante la stessa sessione, sarà necessario accedere ad altri dati del cliente (ad esempio l'indirizzo) per acquistare nuovi articoli.

Per ognuna di queste operazioni è necessario avere tutti questi dati contemporaneamente. Se fossero modellati come documenti separati, sarebbero necessari più round trip al server per creare, aggiornare e recuperare i dati del cliente. Questo non è efficiente.

Modellare le entità cliente

Azure Cosmos DB archivia i dati come JSON, quindi è possibile modellare la relazione uno-a-molti tra Customer e CustomerAddress e incorporare i dati dell'indirizzo del cliente come matrice. Per la relazione uno-a-uno tra Customer e CustomerPassword, è possibile incorporarla come oggetto nel nuovo documento del singolo cliente. L'applicazione di e-commerce può quindi creare, modificare o recuperare i dati del cliente in un'unica richiesta.

Il diagramma seguente illustra l'aspetto dell'entità cliente.

Diagramma che illustra un documento del cliente modellato.