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 in database 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.

Diagram that shows the relational model for customer entities.

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. Queste entità possono essere modellate come documenti separati, ma ciò richiederebbe più round trip al server per creare, aggiornare e recuperare i dati dei clienti.

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.

Diagram that shows a modeled customer document.