Identificare i criteri di accesso per l'app

  • 3 minuti

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 1:Many con CustomerAddress. Il cliente ha una relazione 1:1 con CustomerPassword.

Diagramma che mostra 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, verrà creato un nuovo cliente.
  • Aggiornare un cliente: quando un utente esistente aggiorna le informazioni sul profilo, il record del cliente verrà aggiornato.
  • Recuperare un cliente: quando un utente esistente visita il sito, accederà con la 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 1:Many tra Customer e CustomerAddress e incorporare i dati dell'indirizzo del cliente come matrice. Per la relazione 1:1 tra Customer e CustomerPassword, è possibile incorporarlo come oggetto nel nuovo documento del cliente singolo. 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 mostra un documento del cliente modellato.