Apakah Anda ingin menjadi seorang desainer database? Jika Anda ingin mempelajari tentang cara mendesain database, berikut adalah 11 aturan penting dalam mendesain database menurut Shivprasad Koirala.
Aturan 1: Menentukan sifat aplikasi Anda, apakah OLTP atau OLAP?
Hal pertama yang harus Anda analisis saat medesain database adalah menentukan sifat aplikasi yang Anda rancang, apakah Transactional atau Analytical.
Transactional : Aplikasi semacam ini, cocok untuk end user Anda yang lebih tertarik pada CRUD (Create, Read, Update, Delete). Nama database untuk jenis aplikasi ini adalah OLTP (Online Transaction Processing).
Analytical : Jenis aplikasi ini ditujukan untuk end user Anda yang lebih tertarik pada analisis, pelaporan, perkiraan, dan lain-lain. Jenis database untuk jenis aplikasi ini memiliki lebih sedikit jumlah insert dan update. Tujuan utama di sini adalah untuk mengambil dan menganalisis data secepat mungkin. Nama database untuk jenis aplikasi ini adalah OLAP (Online Analytical Processing).
Dengan kata lain jika Anda ingin adanya proses insert, update, dan delete yang lebih menonjol, maka gunakan desain tabel yang dinormalisasi, selain itu buat struktur database denormalized mendatar.
Di bawah ini adalah diagram sederhana yang menunjukkan bagaimana nama dan alamat di sisi kiri adalah tabel yang dinormalisasi secara sederhana, lalu diterapkan struktur tabel datar.
Aturan 2: Memecah data Anda menjadi potongan-potongan yang sederhana
Ini adalah aturan pertama dari bentuk normal ke-1.
Jika query Anda menggunakan terlalu banyak fungsi penguraian string seperti substring, charindex, dan lain-lain, Anda bisa memecah field sehingga Anda bisa menulis query yang bersih dan optimal. Berikut adalah contoh ketika kita ingin menampilkan nama siswa yang memiliki data “Koirala” dan bukan “Harisingh”.
Aturan 3: Jangan berlebihan dalam menggunakan aturan 2
Anda tidak bisa menerapkan aturan 2 secara berlebihan. Karena tidak semua field bisa diterapkan dengan aturan kedua. Misalnya, Anda ingin menampilkan field nomor telepon. Anda akan jarang beroperasi pada kode ISD nomor telepon secara terpisah, kecuali aplikasi Anda membutuhkannya. Jadi, jika bukan suatu kebutuhan, Anda tidak perlu menggunakan aturan kedua, karena bisa menimbulkan komplikasi.
Aturan 4: Hindari duplikasi data yang tidak seragam
Diagram di bawah ini, Anda dapat melihat “5th Standard” dan “Fifth Standard” memiliki arti yang sama. Sistem akan mengenalinya sebagai entitas yang berbeda saat Anda ngin membuat suatu laporan.
Salah satu solusinya adalah memindahkan data ke tabel master yang berbeda sekaligus dan memberi arah melalui foreign key. Anda dapat melihat pada gambar di bawah ini bagaimana kita telah membuat tabel master baru yang disebut “Standard” dan menautkannya menggunakan foreign key sederhana.
Aturan 5: Perhatikan data yang dipisahkan oleh separator
Aturan kedua dari bentuk normal ke-1 adalah hindari pengulangan suatu grup. Diagram di bawah ini adalah contoh pengulangan suatu grup. Jika Anda melihat field ‘syllabus’ dengan cermat, dalam satu field, kita memiliki terlalu banyak data yang dimasukkan. Jenis-jenis field ini disebut sebagai “Repeating groups“. Jika kita harus memanipulasi data ini, query kita akan menjadi rumit.
Contoh kolom tersebut perlu perhatian khusus. Langkah yang lebih baik adalah memindahkan field tersebut ke tabel yang berbeda dan menghubungkannya dengan key untuk manajemen yang lebih baik.
Untuk menghindari pengulangan grup, Anda dapat melihat pada gambar di atas. Tabel ‘syllabus’ yang terpisah dan kemudian membuat relasi many-to-many dengan tabel ‘subject’.
Dengan pendekatan ini field ‘syllabus’ dalam tabel utama tidak lagi berulang dan memiliki pemisah data.
Aturan 6: Awasi partial dependencies
Perhatikan field yang sebagian bergantung pada primary key. Misalnya, pada tabel di atas kita dapat melihat primary key dibuat pada nomor dan ‘standard’. Sekarang perhatikan field ‘syllabus’ dengan cermat. Bidang ‘syllabus’ diasosiasikan dengan ‘standard’ dan bukan dengan nomor siswa secara langsung.
‘Syllabus’ diasosiasikan dengan ‘standard’ di mana siswa sedang belajar, bukan diasosiasikan secara langsung dengan siswa. Karena jika kita ingin memperbarui ‘syllabus’, kita juga harus memperbarui untuk setiap siswa, hal itu akan melelahkan dan tidak logis. Akan lebih masuk akal jika memindahkan field tersebut dan mengasosiasikannya dengan tabel ‘standard’.
Aturan ini tidak lain adalah bentuk normal ke-2: “Semua key harus bergantung pada primary key lengkap dan bukan sebagian”.
Aturan 7: Hindari redundansi
Jika Anda mengerjakan aplikasi dengan database OLTP, menghapus kolom turunan akan menjadi pilihan yang baik, kecuali ada alasan yang mendesak terkait performance.Pada gambar di atas, Anda dapat melihat bagaimana field ‘average’ bergantung pada ‘marks’ dan ‘subject’. Ini salah satu bentuk redundansi.
Aturan ini juga disebut sebagai bentuk normal ke-3: “Tidak ada kolom yang harus bergantung pada kolom kunci non-primer lainnya”.
Aturan 8: Jangan hindari redundansi jika performance menjadi hal utama
Jangan membuat aturan ketat bahwa Anda akan selalu menghindari redundansi. Jika ada kebutuhan mendesak terkait performance, Anda bisa menerapkan denormalisasi. Dalam normalisasi, Anda perlu membuat gabungan dengan banyak tabel dan dalam denormalisasi untuk meningkatkan performance.
Aturan 9: Data multidimensi
Proyek OLAP sebagian besar berurusan dengan data multidimensi. Contohnya Anda dapat melihat gambar di bawah ini, Anda ingin mendapatkan penjualan per negara, pelanggan, dan tanggal. Dengan kata sederhana, Anda melihat angka penjualan yang memiliki tiga persimpangan data dimensi.
Untuk situasi semacam itu, desain dimensi dan fakta adalah pendekatan yang lebih baik. Dengan kata-kata sederhana Anda dapat membuat tabel fakta penjualan pusat sederhana yang memiliki field jumlah penjualan dan membuat koneksi dengan semua tabel dimensi menggunakan foreign key relationship.
Aturan 10: Desain tabel terpusat
Tabel nama dan nilai berarti memiliki key dan beberapa data yang terkait dengan key. Misalnya pada gambar di bawah ini, Anda dapat melihat tabel mata uang dan tabel negara. Jika Anda mengamati data dengan cermat mereka sebenarnya hanya memiliki satu key dan value.
Untuk jenis tabel seperti itu, membuat tabel pusat dan membedakan data menggunakan tipe field menjadi hal yang lebih mudah dipahami.
Aturan 11: Hirarki data self-reference PK dan FK yang tak terbatas
Sering kali kita menemukan data dengan hierarki parent child yang tidak terbatas. Misalnya, pertimbangkan skenario pemasaran multi-level di mana tenaga penjualan dapat memiliki beberapa tenaga penjualan di bawahnya. Untuk skenario seperti itu, menggunakan self-referencing primary key dan foreign key akan membantu untuk mencapai hal yang sama.
Berikut adalah gambar untuk memudahkan Anda dalam memahami bentuk normal.
Jika Anda tertarik untuk magang atau bekerja menjadi software developer, Anda bisa mendaftarkan diri Anda di magang atau kerja Techarea.
Referensi
Koirala, Shivprasad. 2014. 11 important database designing rules which I follow. [Online] Available at :https://www.codeproject.com/Articles/359654/11-important-database-designing-rules-which-I-fo-2 [Accessed April 10, 2019]
One comment
thanks information