Design Skema Database MongoDB — Baigan 1
Best Praktis Membuat Skema Database yang Benar pada MongoDB — (basic relation)
Saat merancang skema database pada mongoDB atau NoSQL umumnya, kita harus memulai dengan pertanyaan yang tidak akan pernah kita pertimbangkan saat menggunakan rdbms atau sql. Berikut adalah beberapa pertanyaan yang harus kita cari jawabannya.
Apa kardinalitas relasi atau derajat relasi tersebut? Sedalam apa relasi yang terjadi?
Kita perlu mencirikan relasi “Satu-ke-N” dengan nuansa yang sedikit lebih dalam misalkan, apakah itu “satu-ke-sedikit”, “satu-ke-banyak”, atau “satu-ke-squillions (many to one)”? Jadi relasi satu ke N dapat diterjemahkan lebih dalam lagi. Kita akan menggunakan format berbeda untuk memodelkan relasi bergantung pada pemilihan dari hasil pencirian relasi satu ke N tadi.
Banyak yang memulai menggunakan Mongodb sebagai basis data mereka dan berpikir bahwa cara terbaik memodelkan relasi satu-ke-N adalah dengan memasukan atau embedded sub document ke dalam document induk. (Document adalah seperti row pada tabel rdbms). Hanya karena kita dapat meng-embedded document, bukan berarti kita harus selalu melakukannya.
Pemodelan Satu ke Sedikit
Contoh yang mewakili relasi satu ke sedikit adalah relasi antara Person dan Address. Ini merupakan contoh yang bagus untuk kita terapkan teknik embedded. Kita dapat menyimpan data Address berupa array dan menyematkannya ke dalam object Person.
Relasi satu ke sedikit ini dapat turun menjadi relasi satu ke satu jika bagian detail cuma memiliki satu object data seperti berikut.
Dengan cara teknik embedded ini, kita akan mendapatkan beberapa keuntungan dan kerugian. Adapun keuntungannya yaitu, kita cukup melakukan satu kali query untuk mendapatkan data embedded detail. Ketika mendapatkan data Person otomatis akan mendapatkan seluruh Address dari Person tersebut.
Kekurangan utama dari teknik embedded adalah kita tidak memiliki cara untuk dapat mengaksess embended data sebagai entity yang terpisah secara langsung. Dengan demikian, apabila kita ingin melakukan query seperti memunculkan data-data Person yang berkota di New York akan sangat sulit untuk dapat dilakukan.
Pemodelan Satu ke Banyak
Contoh yang mewakili relasi satu ke banyak adalah relasi antara Product dan Part. Satu product akan memiliki banyak part. Lebih detil nya satu product akan memiliki ratusan part akan tetapi satu product tidak memiliki sampai jutaan part. Ini merupakan contoh yang bagus untuk kita terapkan teknik referensi. Kita akan menyimpan data part dalam bentuk array berupa object id dari part-part dan menempatkannya ke dalam product. Berikut adalah document dari Part.
Tiap Product akan memiliki document tersendiri dan memiliki banyak Object Part berupa array dari Part_Id.
Dengan demikian, untuk mendapatkan data-data Part dari sebuah Product, kita harus melakukan query dua kali yang kita lakukan dalam aplikasi kita.
Perhatikan !!! untuk meningkatkan performa, kita harus memiliki index untuk catalog_number sedangkan pada part_id tidak dibutuhkan karena otomatis akan memiliki index dikarenakan sebagai primary key.
Teknik referensi ini merupakan pelengkap dari teknik embedded sehingga kita dapat melakukan pencarian pada bagian detail dengan mudah dan dapat melakukan update data secara individu terlepas dari table master atau tabel induknya.
Salah satu kekurangannya seperti telah dijelaskan di atas yakni kita harus melakukan dua kali query untuk mendapatkan detail. (Kita dapat mempelajari solusinya nanti di bagian penjelasan lebih advance mengenai denormalisasi).
Pemodelan Satu ke Squillions
Agak susah mengartikan relasi satu ke squillions dalam bahasa yang sederhana. Saya mencoba menjelaskannya dengan memandang secara terbalik sebagai relasi banyak ke satu.
Contoh yang mewakili relasi satu ke squillions adalah system log. System log akan menampung log system dari berbagai mesin atau server. Contoh lebih detail seperti Sentry atau Cloud Watch. Ini juga merupakan contoh klasik dari relasi parent-referensi dengan memiliki dokumen tersendiri untuk data host (server) dan dokumen log-message yang memiliki host id dokumen. Jadi pada satu data log message memiliki satu data host id.
Dari penjelasan document Host dan Log message dapat disimpulkan bahwa relasi ini bisa kita pandang sebagai relasi banyak ke satu. Banyak Log message yang terhubung dengan satu Host.
Untuk mencari 5000 log per host tertentu kita dapat melakukan query sebagai berikut.
Dapat kita simpulkan dari penjelasan diatas dalam menterjemahkan relasi satu ke banyak saja kita harus lebih mendalam. Apakah relasi satu ke banyak itu lebih mencerminkan embedded, referensi, atau parrent- referensi.
Selanjutkan akan kita bahas topik lebih advance dari cara kita mendesain skema database pada mongodb yaitu pada bagian Referensi dan Denormalisasi.
“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”
― Linus Torvalds
References
- https://docs.huihoo.com/mongodb/mongodb-3.2-data-models-guide.pdf
- https://docs.huihoo.com/mongodb/10gen-mongodb-operations-best-practices.pdf
Sponsor
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend.
