Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Progettazione dello schema dei pagamenti ricorrenti in DynamoDB
## Caso d'uso aziendale dei pagamenti ricorrenti
Questo caso d'uso parla dell'utilizzo di DynamoDB per implementare un sistema di pagamenti ricorrenti. Il modello di dati ha le seguenti entità: *account*, *sottoscrizioni* e *ricevute*. Le specifiche del nostro caso d'uso includono quanto segue:
+ Ciascun *account* può avere più *sottoscrizioni*
+ La *sottoscrizione* ha un `NextPaymentDate` quando deve essere effettuato il prossimo pagamento e un `NextReminderDate` quando viene inviato un promemoria via e-mail al cliente
+ C'è un articolo per *sottoscrizione* che viene archiviato e aggiornato al momento dell'elaborazione del pagamento (la dimensione media degli articoli è di circa 1 KB e la velocità effettiva dipende dal numero di *account* e *sottoscrizioni*)
+ Il processore del *pagamento* creerà anche una *ricevuta* come parte del processo, che è memorizzato nella tabella ed è impostato per scadere dopo un certo periodo di tempo utilizzando unattributo [TTL](TTL.md)
## Diagramma delle relazioni tra le entità dei pagamenti ricorrenti
Questo è il diagramma delle relazioni tra entità (ERD) che useremo per la progettazione dello schema di gestione dei pagamenti ricorrenti.
![\[Diagramma ERD per un sistema di pagamenti ricorrenti che mostra le entità: Account, Subscription e Receipt.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-1-ERD.png)
## Schemi di accesso ai sistemi di pagamento ricorrenti
Questi sono i modelli di accesso che creeremo per la progettazione dello schema del sistema di pagamenti ricorrenti.
1. `createSubscription`
1. `createReceipt`
1. `updateSubscription`
1. `getDueRemindersByDate`
1. `getDuePaymentsByDate`
1. `getSubscriptionsByAccount`
1. `getReceiptsByAccount`
## Progettazione dello schema dei pagamenti ricorrenti
I nomi generici `PK` e `SK` vengono utilizzati per gli attributi chiave per consentire la memorizzazione di diversi tipi di entità nella stessa tabella, ad esempio le entità account, sottoscrizione e ricevuta. L'utente crea innanzitutto un abbonamento, in cui accetta di pagare un importo lo stesso giorno di ogni mese in cambio di un prodotto. Possono scegliere in quale giorno del mese elaborare il pagamento. C'è anche un promemoria che verrà inviato prima dell'elaborazione del pagamento. L'applicazione funziona con due processi batch eseguiti ogni giorno: un processo batch invia i promemoria con scadenza quel giorno e l'altro processo batch elabora i pagamenti in scadenza quel giorno.
**Fase 1: Gestire il modello di accesso 1 (`createSubscription`)**
Il modello di accesso 1 (`createSubscription`) viene utilizzato per creare inizialmente l'abbonamento e vengono impostati i dettagli, tra cui `SKU`, `NextPaymentDate`, `NextReminderDate` e `PaymentDetails`. Questo passaggio mostra lo stato della tabella per un solo account con un abbonamento. Nella raccolta di articoli possono esserci più abbonamenti, quindi questa è una one-to-many relazione.
![\[Progettazione di una tabella che mostra i dettagli dell’abbonamento per un account.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-2-Step1.png)
**Fase 2: Gestire i modelli di accesso 2 (`createReceipt`) e 3 (`updateSubscription`) **
Il modello di accesso 2 (`createReceipt`) viene utilizzato per creare l'articolo della ricevuta. Dopo l'elaborazione del pagamento ogni mese, il processore di pagamento riscriverà una ricevuta nella tabella di base. Potrebbero esserci più ricevute nella collezione di articoli, quindi questa è una one-to-many relazione. Il processore di pagamento aggiornerà anche l'elemento di abbonamento (Modello di accesso 3 (`updateSubscription`)) da aggiornare per `NextReminderDate`o il `NextPaymentDate` per il prossimo mese.
![\[I dettagli della ricevuta e l’elemento dell’abbonamento vengono aggiornati per mostrare la data del prossimo promemoria di rinnovo.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-3-Step2.png)
**Fase 3: Gestire il modello di accesso 4 (`getDueRemindersByDate`)**
L'applicazione elabora i promemoria per il pagamento in batch per il giorno corrente. Pertanto l'applicazione deve accedere agli abbonamenti su una dimensione diversa: data anziché account. Questo è un buon caso d'uso per l’[indice secondario globale (GSI)](GSI.md). In questo passaggio aggiungiamo l'indice `GSI-1`, che utilizza `NextReminderDate` come chiave di partizione GSI. Non è necessario replicare tutti gli articoli. Questo GSI è un [indice sparso](data-modeling-blocks.md#data-modeling-blocks-sparse-index) e gli articoli delle ricevute non vengono replicati. Inoltre, non è necessario proiettare tutti gli attributi: è sufficiente includere un sottoinsieme degli attributi. L'immagine sotto mostra lo schema di `GSI-1` e fornisce le informazioni necessarie all'applicazione per inviare l'e-mail di promemoria.
![\[Schema di GSI-1 con dettagli, come l’indirizzo email, necessari all’applicazione per inviare un’email di promemoria.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-4-Step3.png)
**Fase 4: Gestire il modello di accesso 5 (`getDuePaymentsByDate`)**
L'applicazione elabora i pagamenti in batch per il giorno corrente nello stesso modo in cui elabora promemoria. In questo passaggio aggiungiamo `GSI-2`, che utilizza `NextPaymentDate` come chiave di partizione GSI. Non è necessario replicare tutti gli articoli. Questo GSI è un indice sparso e gli articoli delle ricevute non vengono replicati. L'immagine sotto mostra lo schema di `GSI-2`.
![\[Schema GSI-2 con dettagli per elaborare i pagamenti. NextPaymentDate è la chiave di partizione per GSI-2.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-5-Step4.png)
**Fase 5: Gestire i modelli di accesso 6 (`getSubscriptionsByAccount`) e 7 (`getReceiptsByAccount`) **
L'applicazione può recuperare tutti gli abbonamenti per un account utilizzando una [query](Query.md) nella tabella di base destinata all'identificatore dell'account (`PK`) e utilizza l'operatore di intervallo per ottenere tutti gli articoli in cui `SK` inizia con “SUB\$1”. L'applicazione può anche utilizzare la stessa struttura di query per recuperare tutte le ricevute utilizzando un operatore di intervallo per ottenere tutti gli articoli in cui `SK` inizia con “REC\$1”. Questo ci consente di soddisfare i modelli di accesso 6 (`getSubscriptionsByAccount`) e 7 (`getReceiptsByAccount`). L'applicazione utilizza questi modelli di accesso in modo che l'utente possa vedere i propri abbonamenti attuali e le ricevute passate degli ultimi sei mesi. Non vi è alcuna modifica allo schema della tabella in questo passaggio e possiamo vedere di seguito come indirizziamo solo gli elementi dell'abbonamento nel modello di accesso 6 (`getSubscriptionsByAccount`).
![\[Risultato dell’operazione di query sulla tabella di base. Mostra l’abbonamento di un account specifico.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-6-Step5.png)
Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:
| Modello di accesso | table/GSI/LSI Base | Operation | Valore della chiave di partizione | Valore della chiave di ordinamento |
| --- | --- | --- | --- | --- |
| createSubscription | Tabella di base | PutItem | ACC\$1account\$1id | SUB\$1\$1SKU |
| createReceipt | Tabella di base | PutItem | ACC\$1account\$1id | REC\$1< > \$1SKU RecieptDate |
| updateSubscription | Tabella di base | UpdateItem | ACC\$1account\$1id | SUB\$1\$1SKU |
| getDueRemindersByDate | GSI-1 | Query | | |
| getDuePaymentsByDate | GSI-2 | Query | | |
| getSubscriptionsByConto | Tabella di base | Query | ACC\$1account\$1id | SK begins\$1with “SUB\$1” |
| getReceiptsByConto | Tabella di base | Query | ACC\$1account\$1id | SK begins\$1with “REC\$1” |
## Schema finale dei pagamenti ricorrenti
Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come file JSON, consulta Esempi di [DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples/blob/master/schema_design/SchemaExamples/ReocurringPayments/ReocurringPaymentsSchema.json) su. GitHub
**Tabella di base**
![\[Progettazione di una tabella di base che mostra le informazioni sull’account e i dettagli dell’abbonamento e della ricevuta.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-7-Base.png)
**GSI-1**
![\[Schema GSI-1 con dettagli dell'abbonamento, come indirizzo e-mail e. NextPaymentDate\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-8-GSI1.png)
**GSI-2**
![\[Schema GSI-2 con dettagli di pagamento, come e. PaymentAmount PaymentDay\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-9-GSI2.png)
## Utilizzo di NoSQL Workbench con questa progettazione dello schema
Puoi importare questo schema finale in [NoSQL Workbench](workbench.md), uno strumento visivo che fornisce funzionalità di modellazione dei dati, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi:
1. Scarica NoSQL Workbench. Per ulteriori informazioni, consulta [Download di NoSQL Workbench per DynamoDB](workbench.settingup.md).
1. Scarica il file dello schema JSON elencato in precedenza, che si trova già nel formato del modello NoSQL Workbench.
1. Importa il file dello schema JSON in NoSQL Workbench. Per ulteriori informazioni, consulta [Importazione di un modello di dati esistente](workbench.Modeler.ImportExisting.md).
1. Dopo che è stato importato in NOSQL Workbench, puoi modificare il modello di dati. Per ulteriori informazioni, consulta [Modifica di un modello di dati esistente](workbench.Modeler.Edit.md).