# DynamoDB での定期払いスキーマの設計
## 定期払いのビジネスユースケース
このユースケースでは、DynamoDB を使用して定期払いシステムを実装する方法について説明します。データモデルには、アカウント、サブスクリプション、領収書のエンティティがあります。******このユースケースの詳細は次のとおりです。
+ アカウントごとに複数のサブスクリプションを持つことができます。****
+ サブスクリプションは、次の支払いを処理する必要があるときは `NextPaymentDate`、E メールによるリマインダーをお客様に送信するときは `NextReminderDate` です。**
+ サブスクリプションには、支払いが処理されると、保存および更新される項目があります (平均の項目サイズは約 1 KB で、スループットはアカウントとサブスクリプションの数によって異なります)。******
+ 支払いプロセッサは、処理の一環として領収書も作成します。領収書は、テーブルに保存され、[TTL](TTL.md) 属性を使用して一定期間後に期限切れになるように設定されます。****
## 定期払いエンティティ関係図
これは、定期払いシステムのスキーマ設計に使用するエンティティ関係図 (ERD) です。
## 定期払いシステムのアクセスパターン
これらは、定期払いシステムのスキーマ設計で検討するアクセスパターンです。
1. `createSubscription`
1. `createReceipt`
1. `updateSubscription`
1. `getDueRemindersByDate`
1. `getDuePaymentsByDate`
1. `getSubscriptionsByAccount`
1. `getReceiptsByAccount`
## 定期払いのスキーマ設計
一般的な名前である `PK` や `SK` は、アカウント、サブスクリプション、領収書などの異なる種類のエンティティを同じテーブルに保存するためのキー属性に使用します。ユーザーは最初にサブスクリプションを作成します。サブスクリプションにより、ユーザーは製品の代金として毎月同じ日に金額を支払うことに同意します。月内のどの日に支払いを処理するかは、ユーザーが選択できます。支払いを処理する前にリマインダーも送信されます。このアプリケーションは、毎日 2 つのバッチジョブを実行することで機能します。1 つのバッチジョブでは、当日を期限とするリマインダーを送信し、もう 1 つのバッチジョブでは、当日を支払期日とするすべての支払いを処理します。
**ステップ 1: アクセスパターン 1 (`createSubscription`) に対処する**
アクセスパターン 1 (`createSubscription`) を使用してサブスクリプションを最初に作成し、`SKU`、`NextPaymentDate`、`NextReminderDate`、`PaymentDetails` などの詳細を設定します。このステップでは、1 つのサブスクリプションで 1 つのアカウントに限り、テーブルの状態を表示します。項目コレクションには複数のサブスクリプションを含めることができるため、これは 1 対多リレーションシップになります。
**ステップ 2: アクセスパターン 2 (`createReceipt`) と 3 (`updateSubscription`) に対処する**
アクセスパターン 2 (`createReceipt`) を使用して領収書項目を作成します。毎月支払いを処理すると、支払いプロセッサは領収書をベーステーブルに書き戻します。項目コレクションには複数の領収書を含めることができるため、これは 1 対多リレーションシップです。支払いプロセッサは、サブスクリプション項目 (アクセスパターン 3 (`updateSubscription`)) も更新し、翌月の `NextReminderDate` または `NextPaymentDate` に変更します。
**ステップ 3: アクセスパターン 4 (`getDueRemindersByDate`) に対処する**
アプリケーションは、当日の支払いのリマインダーをバッチで処理します。そのため、アプリケーションは別のディメンション (アカウントではなく日付) でサブスクリプションにアクセスする必要があります。これは、[グローバルセカンダリインデックス (GSI)](GSI.md) に適したユースケースです このステップでは、インデックス `GSI-1` を追加し、`NextReminderDate` を GSI パーティションキーとして使用します。すべての項目をレプリケートする必要はありません。この GSI は[スパースインデックス](data-modeling-blocks.md#data-modeling-blocks-sparse-index)であり、領収書項目はレプリケートされません。また、すべての属性を射影する必要はなく、属性の一部を含めるだけで済みます。次の図に示す `GSI-1` のスキーマは、アプリケーションがリマインダー E メールを送信するために必要な情報を提供します。
**ステップ 4: アクセスパターン 5 (`getDuePaymentsByDate`) に対処する**
アプリケーションは、リマインダーの場合と同じように、当日の支払いをバッチで処理します。このステップでは `GSI-2` を追加し、`NextPaymentDate` を GSI パーティションキーとして使用します。すべての項目をレプリケートする必要はありません。GSI はスパースインデックスであり、領収書項目はレプリケートされません。次の図は `GSI-2` のスキーマを示しています。
**ステップ 5: アクセスパターン 6 (`getSubscriptionsByAccount`) と 7 (`getReceiptsByAccount`) に対処する**
アプリケーションは、ベーステーブルでアカウント識別子 (`PK`) をターゲットとする[クエリ](Query.md)を使用して、アカウントのすべてのサブスクリプションを取得できます。また、範囲演算子を使用して `SK` が「SUB\#」で始まるすべての項目を取得できます。また、アプリケーションは、同じクエリ構造を使用してすべての領収書を取得し、範囲演算子を使用して `SK` が「REC\#」で始まるすべての項目を取得できます。これにより、アクセスパターン 6 (`getSubscriptionsByAccount`) と 7 (`getReceiptsByAccount`) に対処できます。これらのアクセスパターンをアプリケーションで使用することで、ユーザーは現在のサブスクリプションと過去 6 か月間の領収書を確認できます。このステップでは、テーブルスキーマに変更はありません。アクセスパターン 6 (`getSubscriptionsByAccount`) でサブスクリプション項目だけをターゲットにする方法は次の表で確認できます。
すべてのアクセスパターンと各アクセスパターンにスキーマ設計で対処する方法を次の表にまとめています。
| アクセスパターン | ベーステーブル/GSI/LSI | Operation | パーティションキー値 | ソートキー値 |
| --- | --- | --- | --- | --- |
| CreateSubscription | ベーステーブル | PutItem | ACC\#account\_id | SUB\#\#SKU |
| createReceipt | ベーステーブル | PutItem | ACC\#account\_id | REC\#\#SKU |
| updateSubscription | ベーステーブル | UpdateItem | ACC\#account\_id | SUB\#\#SKU |
| getDueRemindersByDate | GSI-1 | クエリ | | |
| getDuePaymentsByDate | GSI-2 | クエリ | | |
| getSubscriptionsByAccount | ベーステーブル | クエリ | ACC\#account\_id | SK begins\_with “SUB\#” |
| getReceiptsByAccount | ベーステーブル | クエリ | ACC\#account\_id | SK begins\_with “REC\#” |
## Recurring payments final schema
最終的なスキーマ設計は次のとおりです。このスキーマ設計を JSON ファイルとしてダウンロードするには、GitHub の [DynamoDB の例](https://github.com/aws-samples/aws-dynamodb-examples/blob/master/schema_design/SchemaExamples/ReocurringPayments/ReocurringPaymentsSchema.json)を参照してください。
**ベーステーブル**
**GSI-1**
**GSI-2**
## このスキーマ設計での NoSQL Workbench の使用
この最終スキーマを、DynamoDB のデータモデリング、データ視覚化、クエリ開発機能を提供するビジュアルツールである [NoSQL Workbench](workbench.md) にインポートして、新しいプロジェクトを詳しく調べたり編集したりできます。使用を開始するには、次の手順に従います。
1. NoSQL Workbench をダウンロードします。詳細については、「[DynamoDB 用の NoSQL Workbench のダウンロード](workbench.settingup.md)」を参照してください。
1. 上記の JSON スキーマファイルをダウンロードします。このファイルは既に NoSQL Workbench モデル形式になっています。
1. JSON スキーマファイルを NoSQL Workbench にインポートします。詳細については、「[既存のデータモデルのインポート](workbench.Modeler.ImportExisting.md)」を参照してください。
1. NOSQL Workbench にインポートしたら、データモデルを編集できます。詳細については、「[既存のデータモデルの編集](workbench.Modeler.Edit.md)」を参照してください。