Pemodelan hubungan

Artikel ini membahas proses pemodelan, untuk membantu Anda mendesain solusi penyimpanan Azure Table Anda.

Membangun model domain adalah langkah kunci dalam desain sistem yang kompleks. Biasanya, Anda menggunakan proses pemodelan untuk mengidentifikasi entitas dan hubungan di antara mereka, sebagai cara untuk memahami domain bisnis dan menginformasikan desain sistem Anda. Bagian ini berfokus pada bagaimana Anda dapat menerjemahkan beberapa jenis hubungan umum yang ditemukan, dalam model domain ke desain untuk layanan Table. Proses pemetaan dari model data logis ke model data berbasis NoSQL fisik berbeda dari yang digunakan saat merancang database hubungan. Desain database hubungan biasanya mengasumsikan proses normalisasi data yang dioptimalkan untuk meminimalkan redundansi - dan kemampuan kueri deklaratif yang mengabstraksi bagaimana implementasi cara kerja database.

Hubungan satu ke banyak

Hubungan satu ke banyak antara objek domain bisnis sering terjadi: misalnya, satu departemen memiliki banyak karyawan. Ada beberapa cara untuk mengimplementasikan hubungan satu ke banyak dalam layanan Table masing-masing, dengan pro dan kontra yang mungkin relevan dengan skenario tertentu.

Pertimbangkan contoh perusahaan multi-nasional/regional besar dengan puluhan ribu departemen dan entitas karyawan di mana setiap departemen memiliki banyak karyawan dan setiap karyawan yang terkait dengan satu departemen tertentu. Salah satu pendekatannya adalah menyimpan departemen dan entitas karyawan yang terpisah seperti ini:

Contoh ini menunjukkan hubungan implisit satu ke banyak antara jenis berdasarkan nilai PartitionKey. Setiap departemen dapat memiliki banyak karyawan.

Contoh ini juga menunjukkan entitas departemen dan entitas karyawan terkait dalam partisi yang sama. Anda dapat memilih untuk menggunakan partisi, tabel, atau bahkan akun penyimpanan yang berbeda untuk berbagai jenis entitas.

Pendekatan alternatifbya adalah dengan denormalisasi data Anda, dan hanya menyimpan entitas karyawan dengan data departemen yang dinormalisasi seperti yang ditunjukkan dalam contoh berikut. Dalam skenario khusus ini, pendekatan denormalisasi ini mungkin bukan yang terbaik jika Anda memiliki persyaratan untuk dapat mengubah detail manajer departemen, karena untuk melakukan ini, Anda harus memperbarui setiap karyawan di departemen.

Untuk informasi selengkapnya, lihat Pola denormalisasi nanti di panduan ini.

Tabel berikut ini merangkum pro dan kontra dari setiap pendekatan yang diuraikan di atas untuk menyimpan entitas karyawan dan departemen yang memiliki hubungan satu-ke-banyak. Anda juga harus mempertimbangkan seberapa sering Anda akan melakukan berbagai operasi: mungkin dapat diterima untuk memiliki desain yang mencakup operasi mahal hanya jika operasi tersebut jarang terjadi.

Pendekatan	Pro	Kontra
Pisahkan jenis entitas, partisi yang sama, tabel yang sama	Anda dapat memperbarui entitas departemen dengan satu operasi. Anda dapat menggunakan Transaksi Grup Entitas* (EGT) untuk mempertahankan konsistensi, jika Anda memiliki persyaratan untuk memodifikasi entitas departemen setiap kali Anda memperbarui/menyisipkan/menghapus entitas karyawan. Misalnya, jika Anda mempertahankan jumlah karyawan departemen untuk setiap departemen.	Anda mungkin harus mengambil entitas karyawan dan departemen untuk beberapa aktivitas klien. Operasi penyimpanan terjadi dalam partisi yang sama. Pada volume transaksi tinggi, ini dapat mengakibatkan hotspot. Anda tidak dapat memindahkan karyawan ke departemen baru menggunakan EGT.
Pisahkan jenis entitas, partisi atau tabel atau akun penyimpanan yang berbeda	Anda dapat memperbarui entitas departemen atau entitas karyawan dengan satu operasi. Pada volume transaksi tinggi, ini dapat membantu menyebarkan beban di lebih banyak partisi.	Anda mungkin harus mengambil entitas karyawan dan departemen untuk beberapa aktivitas klien. Anda tidak dapat menggunakan EGT untuk mempertahankan konsistensi saat memperbarui/menyisipkan/menghapus karyawan dan memperbarui departemen. Misalnya, memperbarui jumlah karyawan di entitas departemen. Anda tidak dapat memindahkan karyawan ke departemen baru menggunakan EGT.
Denormalisasi menjadi jenis entitas tunggal	Anda dapat mengambil semua informasi yang Anda butuhkan dengan satu permintaan.	Biaya untuk menjaga konsistensi mungkin mahal jika Anda harus memperbarui informasi departemen (ini akan mengharuskan Anda memperbarui semua karyawan di departemen).

*Untuk informasi selengkapnya, lihat Transaksi Grup Entitas

Bagaimana Anda memilih antara opsi ini, dan pro dan kontra mana kah yang paling signifikan, tergantung pada skenario aplikasi spesifik Anda. Misalnya, seberapa sering Anda memodifikasi entitas departemen; melakukan semua kueri karyawan Anda memerlukan informasi departemen tambahan; seberapa dekat Anda dengan batas skalabilitas pada partisi atau akun penyimpanan Anda?

Hubungan satu ke satu

Model domain dapat mencakup hubungan satu ke satu antar entitas. Jika Anda perlu menerapkan hubungan satu-ke-satu dalam layanan Table, Anda juga harus memilih cara menautkan dua entitas terkait ketika Anda harus mengambilnya keduanya. Tautan ini dapat berupa implisit, berdasarkan konvensi dalam nilai kunci, atau eksplisit dengan menyimpan tautan dalam bentuk nilai PartitionKey dan RowKey di setiap entitas ke entitas terkait. Untuk membahas apakah Anda harus menyimpan entitas terkait dalam partisi yang sama, lihat bagian Hubungan satu-ke-banyak.

Ada juga pertimbangan implementasi yang mungkin menuntun Anda untuk mengimplementasikan hubungan satu-ke-satu dalam layanan Table:

• Menangani entitas besar (untuk informasi selengkapnya, lihat Pola Entitas Besar).
• Menerapkan kontrol akses (untuk informasi selengkapnya, lihat Mengontrol akses dengan Tanda Tangan Akses Bersama).

Bergabung dalam klien

Meskipun ada cara untuk memodelkan hubungan dalam layanan Table, Anda tidak boleh lupa bahwa dua alasan utama untuk menggunakan layanan Table adalah skalabilitas dan performa. Jika Anda menyadari telah memodelkan banyak hubungan yang membahayakan performa dan skalabilitas solusi Anda, Anda harus bertanya pada diri sendiri apakah diperlukan membangun semua hubungan data ke dalam desain tabel Anda. Anda mungkin dapat menyederhanakan desain dan meningkatkan skalabilitas dan performa solusi Anda, jik membiarkan aplikasi klien Anda melakukan gabungan yang diperlukan.

Misalnya, jika Anda memiliki tabel kecil yang berisi data yang tidak sering berubah, maka Anda dapat mengambil data ini sekali dan menyimpannya di klien. Ini dapat menghindari bolak-balik berulang untuk mengambil data yang sama. Dalam contoh yang telah kita lihat dalam panduan ini, sekumpulan departemen dalam organisasi kecil datanya cenderung kecil dan jarang berubah, ini menjadi kandidat yang baik untuk data yang dapat diunduh satu kali oleh aplikasi klien dan cache sebagai pencarian data.

Hubungan warisan

Jika aplikasi klien Anda menggunakan serangkaian kelas yang merupakan bagian dari hubungan warisan untuk mewakili entitas bisnis, Anda dapat dengan mudah mempertahankan entitas tersebut dalam layanan Table. Misalnya, Anda mungkin memiliki serangkaian kelas berikut yang ditentukan dalam aplikasi klien Anda di mana Person adalah kelas abstrak.

Anda dapat mempertahankan instans dua kelas konkret dalam layanan Table, menggunakan tabel Person tunggal menggunakan entitas yang terlihat seperti ini:

Untuk informasi selengkapnya tentang bekerja dengan beberapa jenis entitas dalam tabel yang sama dalam kode klien, lihat bagian Bekerja dengan jenis entitas heterogen nanti dalam panduan ini. Bagian ini memberikan contoh cara mengenali jenis entitas dalam kode klien.

Langkah berikutnya

• Pola desain tabel
• Mendesain kueri
• Mengenkripsi data tabel
• Mendesain modifikasi data