Normal Database vs Denormal Database

Setelah menghadapi dua proyek dalam occasion yang berbeda dan dua-duanya dihadapi pada database, akhirnya gue mengerti apa maksud dari perkataan Bu Putri(kaprodi IF periode itu) dalam paparannya di kuliah IF2xxx dengan judul Basis Data.

Sore itu, seperti biasa bagi mereka yang hobi tidur di kelas pelajaran itu sangat menegangkan karena sedikit saja kepala jatuh pasti kita diomel-omelin. Lain cerita sore itu gue lagi dalam kondisi fokus sefokus-fokusnya. Gara-gara sore itu pula dulu gue sempet terpikir untuk mendalami bidang database. Sore itu juga alasan gue lebih memilih mengambil kuliah Sistem Basis Datanya Pak Ben ketimbang Grafika karena gue jadi suka database. (Walaupun pada akhirnya kecintaan gue pada database hilang sehilang-hilangnya usai mengambil kuliah Sistem Basis Data @#$%^&*()@$%#&). Gue mengakui sih, mereka yang telaten dan mau mendalami bidang database akan sukses, minimal satu posisi penting di Bank Indonesia bisa mereka peroleh bagi yang mau mendalaminya.

Back to topic. Sore itu Bu Putri menjelaskan tentang normalisasi. Penjelasannya masih abstrak tapi cukup enak dimengerti dengan pemisalan-pemisalan tabel, relasi, entitas, field, dan lainnya.

Apa sih yang dimaksud dengan Database Normal? Bahasa kuliahnya?

Lo mesti buat suatu tabel sampai Normal Level 3 atau 3N. Caranya? Hahaha sudah lupa! (bentar cek buku sakti Silberschatz dulu). Poin gue adalah database normal adalah suatu state dimana database tersebut sama sekali tidak redundan. Ambilah contoh seperti ini :

Ada database yang memiliki tabel A dan B

A : a_id, nama, nomor, alamat, nilai

B : b_id, nama, hobby

Apakah database tersebut normal? Jawabannya tidak normal. Lalu bagaimana supaya database tersebut normal? Kalau gue masih inget caranya gue akan mengajari kalian supaya mentransformasi database tersebut ke 1N, lalu ke 2N, dan terakhir 3N. Lalu dari 3N masih ada terusannya sih. I’m just so forgetful. Let’s move on.

Kita analisis sendiri aja yuk. Apa yang aneh?

  • Nilai bisa banyak (one to many) sehingga sangat redundan kalau setiap kali membuat nilai baru kita harus membuat record yang baru juga.
  • Tabel B sebenarnya apa sih? harusnya kalau kita jeli itu akan terlihat seperti tabel hobby kan ya? sementara tabel A seperti tabel mahasiswa atau semacamnya, betul?

Coba kita ubah sedikit :

Mahasiswa – A : a_id, nama, nomor, alamat

Score – S : a_id, nilai, date

Hobby – B : b_id, nama, hobby

Seems better? Masih ada yang aneh? Yeah, betul. Nama pada tabel B menurut gue juga redundan karena sudah ada di tabel A. Memang benar bahwa hobby juga hubungan 1 ke banyak. Jadi sebaiknya tabel B kita ubah saja seperti ini :

Hobby – B : a_id, hobby

Nah, dengan begitu nama bisa ngikut tabel A aja. Fyi, b_id kita hilangin saja ya, karena sifatnya hanya FK. Kecuali memang di setiap tabel ada kebutuhan diberikan ID.

Jadi database normalnya kira-kira seperti ini… et voila…

Mahasiswa – A : a_id, nama, nomor, alamat

Score – S : a_id, nilai, date

Hobby – B : a_id, hobby

Di akhir kuliah, Bu Putri bilang begini ke mahasiswanya, “Tapi ada kalanya database yang normal perlu di denormalisasi. Yah, silakan pelajari sendiri. Kita akhiri kuliah hari ini.”

DAMN IT, padahal lagi seru-serunya.

***

Barulah dalam beberapa bulan ini gue berkesempatan ikut mendesain database yang scopenya cukup gede. Dan gue pada akhirnya berhasil membuat database yang saaaaaangat NORMAL!!! yah kalo boleh dikasih persen 95% dari semua desain tabelnya sudah normal.

Tapi apa yang terjadi kemudian? Ketika kita mulai mendevelop websitenya — lebih tepatnya ketika kita mendevelop sudah sampai tahapan 70% jadi — barulah gue menyadari betapa normalnya database yang sudah kami buat.

Keuntungan dari database yang normal adalah semua tabel dipastikan tidak akan redundan, dan pasti dapat diakses. Begitu diubah satu akan berubah semua data yang berhubungan dengannya. Data pasti konsisten.

Konsekuensi database normal?

Yang pertama database akan gemuk dengan tabel (akan ada banyak tabel). Konsekuensi yang wajar mengingat kasus contoh mahasiswa-score-hobby di atas dimana ketika ada ada data yang redundan atau 1 ke banyak atau banyak ke banyak maka harus dibuat tabel yang baru. Jika kebutuhan database kecil maka hal ini bukan masalah. Tapi jika jenis informasi yang ingin disimpan sangat banyak maka jumlah tabel akan sangat banyak.

Yang kedua dan yang paling penting. Ini merupakan konsekuensi dari konsekuensi yang pertama. Bayangkan saja pada tabel yang tidak normal kita sudah harus melakukan join dengan 3 tabel. Kemudian setelah normalisasi tabel tersebut tercacah menjadi beberapa tabel lain, anggap saja 6 tabel. Berarti untuk memperoleh data yang sama kita harus melakukan join terhadap 6 tabel. Dengan database yang sangat normal sistem harus mengeluarkan effort lebih untuk mengeluarkan data yang sama.

***

Ambil saja contoh pada proyek gue yang terbaru.

Sebelum dinormalisasi terdapat tabel customer yang memiliki field receivable_amount (hutang customer). Di tabel lain, sales_order, yang menyimpan informasi pembelian oleh customer tersebut, memiliki field customer_id, dan price_amount. Sementara terdapat tabel invoice yang menyimpan info payment dari customer tersebut (terdapat field customer_id, dan payment_amount). Ringkasannya seperti ini :

customer  : customer_id, receivable_amount, …

sales_order : sales_order_id, customer_id, price_amount, …

invoice : invoice_id, customer_id, payment_amount, …

Kalau kita mau berbicara NORMAL maka sebenarnya field receivable_amount (hutang customer) tidak perlu ada karena kita bisa menghitungnya dari :

receivable_amount =

Jumlah semua  price_amount untuk customer_id tersebut – Jumlah semua payment_amount untuk customer_id

Sehingga receivable_amount dapat kita hapus jika mau databasenya normal.

Well, waktu ngedesain database seperti itu, lalu tibalah saat kami mendevelop kodenya. Waktu coding insertnya sih masih gampang. Eh begitu masuk tahapan coding READ, bahkan dengan data(rows) yang masih sedikit saja loadingnya sudah cukup berat.

Ingat pernyataan gue sebelumnya?  Sistem harus mengeluarkan effort lebih untuk mengeluarkan data yang samaBarulah gue menyesal dengan keputusan normalisasi tersebut. Sebagai catatan selain tiga tabel tersebut mereka juga harus dijoin dengan beberapa tabel lain. Selain join, nested query pun harus dilakukan padahal nested prosesnya lebih berat dari join.

Kalau mau databasenya normal tapi sedikit tidak normal :p yakni dengan menambah field receivable_amount di tabel customer semuanya akan lebih mudah.

Keuntungannya? Kita cukup mengambil satu field receivable_amount untuk menampilkan informasi hutang customer.

Konsekuensinya?

Dari sudut pandang database,  data kita konsistensinya pasti tidak akan terjamin. Nilai pada field receivable_amount BELUM TENTU SAMA DENGAN (jumlah semua  price_amount untuk customer_id tersebut – Jumlah semua payment_amount untuk customer_id tersebut). Semuanya tergantung dari sistem yang dibuat (website yang dibuat).

Kalau mau databasenya tidak normal maka setiap kali customer MEMBUAT sales_order, sistem(web) secara manual harus MENAMBAH nilai receivable_amount sesuai dengan jumlah price_amount.

Juga ketika setiap customer MEMBUAT invoice, sistem(web) secara manual harus MENGURANGI nilai receivable_amount sesuai dengan jumlah payment_amount.

Dengan database yang tidak normal SISTEM harus mendesain agar data selalu konsisten. Dengan keuntungan kita dapat mengaksesnya lebih mudah. Dalam opini gue untuk kasus receivable_amount ini, effort untuk membuat sistem yang bisa menjaga data receivable_amount konsisten (kalau seandainya dulu di denormalisasi databasenya) jauh lebih mudah dibandingkan harus melakukan join ke 6-8 tabel plus nested query yang sangat annoying.

***

Lalu pertanyaan gue adalah kapan kita harus melakukan denormalisasi database seperti yang Bu Putri bilang dulu? Ada ilmunya kah? atau kita harus pintar-pintar menalar menimbang mana yang harus dikorbankan antara : Sistem Web yang bisa menjaga konsistensi data (Dalam database tidak normal) VS Sistem database yang normal? Still a question to me.

Enough with geek talk today! Good Morning Everybody😀

2 pemikiran pada “Normal Database vs Denormal Database

    • kuliah yang basis data emang masih enak sih buat non-prodi. Lumayan pengetahuan dasar tentang basis data. Kita bisa dapetin logicnya gimana buat basis data yang bagus.

      Tapi kuliah basis data setelahnya sebaiknya ga usah diambil😐

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s