Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Desain skema pembayaran berulang di DynamoDB
<a name="data-modeling-schema-recurring-payments"></a>

## Kasus penggunaan bisnis pembayaran berulang
<a name="data-modeling-schema-recurring-payments-use-case"></a>

Kasus penggunaan ini membahas penggunaan DynamoDB untuk menerapkan sistem pembayaran berulang. Model data memiliki entitas berikut: *akun*, *langganan*, dan *tanda terima*. Spesifikasi untuk kasus penggunaan kita meliputi hal berikut:
+ Setiap *akun* dapat memiliki beberapa *langganan*
+ *Langganan* memiliki `NextPaymentDate` ketika pembayaran berikutnya perlu diproses dan `NextReminderDate` ketika pengingat email dikirim ke pelanggan
+ Ada item untuk *langganan* yang disimpan dan diperbarui saat pembayaran diproses (ukuran item rata-rata sekitar 1 KB dan throughput-nya tergantung jumlah *akun* dan *langganan*)
+ Pemroses *pembayaran* juga akan membuat *tanda terima* sebagai bagian dari proses yang disimpan dalam tabel dan diatur agar kedaluwarsa setelah jangka waktu tertentu dengan menggunakan atribut [TTL](TTL.md)

## Diagram hubungan entitas pembayaran berulang
<a name="data-modeling-schema-recurring-payments-erd"></a>

Ini adalah diagram hubungan entitas (ERD) yang akan kita gunakan untuk desain skema sistem pembayaran berulang.

![ERD sistem pembayaran berulang yang menunjukkan entitas: Akun, Langganan, dan Tanda Terima.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-1-ERD.png)


## Pola akses sistem pembayaran berulang
<a name="data-modeling-schema-recurring-payments-access-patterns"></a>

Ini adalah pola akses yang akan kita pertimbangkan untuk desain skema pembayaran berulang.

1. `createSubscription`

1. `createReceipt`

1. `updateSubscription`

1. `getDueRemindersByDate`

1. `getDuePaymentsByDate`

1. `getSubscriptionsByAccount`

1. `getReceiptsByAccount`

## Desain skema pembayaran berulang
<a name="data-modeling-schema-recurring-payments-design-evolution"></a>

Nama generik `PK` dan `SK` digunakan untuk atribut kunci guna memungkinkan penyimpanan berbagai jenis entitas dalam tabel yang sama seperti entitas akun, langganan, dan tanda terima. Pertama, pengguna membuat langganan dan setuju untuk membayar sejumlah biaya pada hari yang sama setiap bulan sebagai harga atas suatu produk. Pengguna dapat memilih salah satu hari dalam sebulan untuk memproses pembayaran. Terdapat juga pengingat yang akan dikirim sebelum pembayaran diproses. Aplikasi bekerja dengan menjalankan dua tugas batch yang berjalan setiap hari: satu tugas batch mengirimkan pengingat yang jatuh tempo hari itu dan tugas batch lainnya memproses semua pembayaran yang jatuh tempo hari itu.

**Langkah 1: Tangani pola akses 1 (`createSubscription`)**

Pola akses 1 (`createSubscription`) awalnya digunakan untuk membuat langganan, dan detail yang mencakup `SKU`, `NextPaymentDate`, `NextReminderDate`, dan `PaymentDetails` diatur. Langkah ini menunjukkan status tabel hanya untuk satu akun dengan satu langganan. Mungkin ada beberapa langganan dalam koleksi item jadi ini adalah one-to-many hubungan.

![Desain tabel yang menunjukkan detail langganan untuk akun.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-2-Step1.png)


**Langkah 2: Tangani pola akses 2 (`createReceipt`) dan 3 (`updateSubscription`)**

Pola akses 2 (`createReceipt`) digunakan untuk membuat item tanda terima. Setelah pembayaran diproses setiap bulan, pemroses pembayaran akan menulis tanda terima kembali ke tabel dasar. Di sana, bisa ada beberapa tanda terima dalam koleksi item jadi ini adalah one-to-many hubungan. Pemroses pembayaran juga akan memperbarui item langganan (Pola akses 3 (`updateSubscription`)) untuk memperbarui `NextReminderDate` atau `NextPaymentDate` bulan berikutnya.

![Detail tanda terima dan pembaruan item langganan untuk menampilkan tanggal pengingat langganan berikutnya.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-3-Step2.png)


**Langkah 3: Tangani pola akses 4 (`getDueRemindersByDate`)**

Aplikasi memproses pengingat untuk pembayaran dalam batch untuk hari ini. Oleh karena itu, aplikasi perlu mengakses langganan pada dimensi yang berbeda, yaitu tanggal, bukan akun. Kasus penggunaan ini bagus untuk [indeks sekunder global (GSI)](GSI.md). Pada langkah ini kita menambahkan indeks `GSI-1`, yang menggunakan `NextReminderDate` sebagai kunci partisi GSI. Kita tidak perlu mereplikasi semua item. GSI ini adalah [indeks jarang](data-modeling-blocks.md#data-modeling-blocks-sparse-index) dan item tanda terima tidak direplikasi. Kita juga tidak perlu memproyeksikan semua atribut—kita hanya perlu menyertakan subset atribut. Gambar di bawah ini menunjukkan skema `GSI-1` dan memberikan informasi yang diperlukan aplikasi untuk mengirim email pengingat.

![Skema GSI-1 dengan detail, seperti alamat email, aplikasi perlu mengirim email pengingat.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-4-Step3.png)


**Langkah 4: Tangani pola akses 5 (`getDuePaymentsByDate`)**

Aplikasi memproses pembayaran dalam batch untuk hari ini dengan cara yang sama seperti pengingat. Kita menambahkan indeks `GSI-2` pada langkah ini, yang menggunakan `NextPaymentDate` sebagai kunci partisi GSI. Kita tidak perlu mereplikasi semua item. GSI ini adalah indeks jarang dan item tanda terima tidak direplikasi. Gambar di bawah ini menunjukkan skema `GSI-2`.

![Skema GSI-2 dengan detail untuk memproses pembayaran. NextPaymentDate adalah kunci partisi untuk GSI-2.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-5-Step4.png)


**Langkah 5: Tangani pola akses 6 (`getSubscriptionsByAccount`) dan 7 (`getReceiptsByAccount`)**

Aplikasi dapat mengambil semua langganan untuk akun dengan menggunakan [kueri](Query.md) pada tabel dasar yang menargetkan pengidentifikasi akun (`PK`) dan menggunakan operator rentang untuk mendapatkan semua item dengan “SUB\#” sebagai awalan `SK`. Aplikasi juga dapat menggunakan struktur kueri yang sama untuk mengambil semua tanda terima menggunakan operator rentang untuk mendapatkan semua item dengan “REC\#” sebagai awalan `SK`. Hal ini memungkinkan kita memenuhi pola akses 6 (`getSubscriptionsByAccount`) dan 7 (`getReceiptsByAccount`). Aplikasi menggunakan pola akses tersebut sehingga pengguna dapat melihat langganan saat ini dan tanda terima lama mereka selama enam bulan terakhir. Tidak ada perubahan pada skema tabel dalam langkah ini dan kita dapat melihat di bawah ini bagaimana kita hanya menargetkan item berlangganan dalam pola akses 6 (`getSubscriptionsByAccount`).

![Hasil operasi query pada tabel dasar. Ini menunjukkan berlangganan akun tertentu.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-6-Step5.png)


Semua pola akses dan bagaimana desain skema mengatasinya dirangkum dalam tabel di bawah ini:


| Pola akses | Basis table/GSI/LSI | Operasi | Nilai kunci partisi | Nilai kunci urutan | 
| --- | --- | --- | --- | --- | 
| createSubscription | Tabel dasar | PutItem | ACC\#account\_id | SUB\#<SUBID>\#SKU<SKUID> | 
| createReceipt | Tabel dasar | PutItem | ACC\#account\_id | REC\#< > \#SKU RecieptDate <SKUID> | 
| updateSubscription | Tabel dasar | UpdateItem | ACC\#account\_id | SUB\#<SUBID>\#SKU<SKUID> | 
| getDueRemindersByDate | GSI-1 | Kueri | <NextReminderDate> |  | 
| getDuePaymentsByDate | GSI-2 | Kueri | <NextPaymentDate> |  | 
| getSubscriptionsByAkun | Tabel dasar | Kueri | ACC\#account\_id | SK begins\_with “SUB\#” | 
| getReceiptsByAkun | Tabel dasar | Kueri | ACC\#account\_id | SK begins\_with “REC\#” | 

## Skema akhir pembayaran berulang
<a name="data-modeling-schema-recurring-payments-final-schema"></a>

Berikut adalah desain skema akhir. [Untuk mengunduh desain skema ini sebagai file JSON, lihat Contoh DynamoDB di.](https://github.com/aws-samples/aws-dynamodb-examples/blob/master/schema_design/SchemaExamples/ReocurringPayments/ReocurringPaymentsSchema.json) GitHub

**Tabel dasar**

![Desain tabel dasar yang menampilkan informasi akun, serta detail langganan dan tanda terima.](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-7-Base.png)


**GSI-1**

![Skema GSI-1 dengan rincian berlangganan, seperti alamat email dan. NextPaymentDate](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-8-GSI1.png)


**GSI-2**

![Skema GSI-2 dengan rincian pembayaran, seperti dan. PaymentAmount PaymentDay](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/ReoccurringPayments-9-GSI2.png)


## Menggunakan NoSQL Workbench dengan desain skema ini
<a name="data-modeling-schema-recurring-payments-nosql"></a>

Anda dapat mengimpor skema akhir ini ke [NoSQL Workbench](workbench.md), sebuah alat visual yang menyediakan fitur pemodelan data, visualisasi data, dan pengembangan kueri untuk DynamoDB, guna mengeksplorasi dan mengedit proyek baru Anda lebih lanjut. Ikuti langkah-langkah berikut untuk memulai:

1. Unduh NoSQL Workbench. Untuk informasi selengkapnya, lihat [Unduh NoSQL Workbench untuk DynamoDB](workbench.settingup.md).

1. Unduh file skema JSON yang tercantum di atas, yang sudah dalam format model NoSQL Workbench.

1. Impor file skema JSON ke NoSQL Workbench. Untuk informasi selengkapnya, lihat [Mengimpor model data yang ada](workbench.Modeler.ImportExisting.md). 

1. Setelah mengimpor model data ke NoSQL Workbench, Anda dapat mengeditnya. Lihat informasi yang lebih lengkap di [Mengedit model data yang ada](workbench.Modeler.Edit.md).